WO2005057510A1

WO2005057510A1 - Authentication method and system

Info

Publication number: WO2005057510A1
Application number: PCT/IB2004/052754
Authority: WO
Inventors: Robyne Anne Conway; Jason Peter Berry; Paul Sheer
Original assignee: Robyne Anne Conway; Jason Peter Berry; Paul Sheer
Priority date: 2003-12-10
Filing date: 2004-12-10
Publication date: 2005-06-23

Abstract

This invention relates to an authentication system and method and more particularly, to an authentication method and system for authenticating a device such as a bank card and/or the user thereof. An authentication method comprising the steps of: communicating a device to be authenticated with an authentication server station so that the server station transmits a first code; receiving the first code from the server station; entering the code manually on an manual input means on the device; transmitting a second code provided by the device in response to inputting the first code into the device, to the server station.

Description

AUTHENTICATION METHOD AND SYSTEM

FIELD OF THE INVENTION

This invention relates to an authentication system and method and more particularly, to an authentication method and system for authenticating a device such as a bank card and/or the user thereof.

BACKGROUND OF THE INVENTION

Methods and systems having measures for secure communications are well known and widely used. Such methods and systems are however not entirely secure and may be compromised under certain conditions.

Cardis Enterprises International BV, in a document entitled "PlNcard - the portable security platform for securing data and payments for Internet and Mobile Commerce environments", stated that:

"Payments over the internet today are a gamble, yet payment is fundamental to all internet transactions and services. A number of initiatives have been promoted to address the growing need for mutual authentication (consumer and merchant) and consumer certification where the transacting parties are not face to face. Such initiatives are obviously welcome, but many tend to lack the need for ubiquity, ease and simplicity of use, portability, cost effective and can be implemented into existing infrastructures. Data entry which cannot be modified or intercepted by a 3^rd party is important for: Non-repudiation Security of sensitive data Trust by recipient Confidence by user

What is needed is a universal solution that meets these needs and those of merchants, banks and consumers alike- this is the philosophy behind PlNcard." They the proceed to disclose a solution as follows:

'The PlNcard concept

PlNcard - a patent pending innovation by Cardis, aims to address these shortcomings by combining smart cart payment technology with authentication and identification techniques in a single package and in a unobtrusive way. The basic innovation is to combine a payment card (e.g. EMV debit or credit card) with a PIN pad function in the standard IDI credit card size form factor. This allows a PIN code to be checked on board the smart card, thereby enhancing the overall system security and makes it useable over open public networks. This in itself is not a new concept - what makes PlNcard a fresh approach is that the in card pressure sensitive PIN pad function is both invisible in terms of the graphics on the face of the card and also passive until inserted into a card reader. So the card appears like any regular payment card with the full card face (and reverse) being available for "real estate" and branding. In effect, the PIN pad is invisibly embedded within the plastic card.

PlNcard Operation

To use a PlNcard you simply insert the card into a frame (card connector and reader/writer) say, connected to the serial port of a PC - this reader includes a marked access area with either a deformable layer or press-thru holes. The handshake between the card and the connector establishes the logical addressing and mapping of the bidden PIN pad so that PIN entry arid/or the amount of the transaction can be input through the press-thru holes. The smart card's security architecture (operator defined) handles the cryptography and digital certificates are generated and passed as part of the message format over the network into the settlement system.

The card can be inserted in any direction into the frame (top down, bottom up, left side and right side) allowing maximum flexibility for card reader/writer design (e.g. a PlNcard insertion in a mobile phone may be into the side of the handset). An added advantage here is that wear and tear on the card will not highlight the pressure sensitive areas commonly used on the same PIN entry as the logical address will change with each orientation - this provides additional security as would be fraudsters cannot visually detect the character areas of the PIN."

The PlNcard concept provides a useful device for use in secure communications. It does not, however, necessarily provide a method or system for secure communications on its own.

The misrepresentation of identity should not be possible in an ideal authentication system. With regard to authentication systems, design in anticipation of every avenue of misuse, malicious attack, and fraud is rarely anticipated, and therefore most commercial systems are vulnerable due to their design, which is, to work well only when the system is used correctly as intended.

Electronic communications and transactions legislation around the world takes cognizance of the existing vulnerabilities and security weaknesses relating directly to the true authentication of individuals' identities when communicating or transacting electronically. Legislatures do so by raising the bar for higher levels of digital certificates, commonly known as advanced electronic signatures (used when the law requires or for many government transactions) to include face-to-face procedures at issuing.

It is important to note that preferred authentication service providers (in the South African context, the Post Office) acting as trusted third parties, governed by a code of conduct alone can provide face-to-face procedures. The reasons for this are two-fold: An ability to cross-check and authenticate personal information against government data is necessary, for example, an identification document (ID) number or birth certificate.

One can currently obtain a digital certificate or signature without undergoing face-to-face procedures by getting a referee known to the issuing organization or of high standing to vouch for you remotely, providing a working email address and response to the emails sent to you at that address. This is not sufficient to ensure the identity of a person is authentic, nor does it always meet the requirements of legislation.

Authentication solution that sets out to address all the legal requirements for advanced electronic signatures and the problems of identity fraud and theft must embrace the use of face-to-face procedures at issuing, as a core component of the solution.

In addition, the face-to-face contact with individuals should be leveraged to compile clean and current personal information that is protected by trusted third party codes of conduct, as an integral part of the security infrastructure of the overall solution.

The most common card authentication mechanism used today is the magnetic strip bank. This authentication mechanism makes an assumption that causes it to be insecure by its very nature: it relies on the ATM machine being trustworthy. Should an electronic device with it communicated such as an ATM machine be fake, the attacker not only gets all the data on the card, but the user's numeric confidential pin code as well.

Therefore, as a first step, any authentication system must assume that the device into which a card is being placed is untrusted.

Non-magnetic card systems, like smart-card systems often assume tamper resistance. By purporting that information cannot be forcefully extracted from the card, security is ensured. However, smart card systems may not be entirely secure. Hence the second requirement of an authentication system is that it be immune to tamper. This means that even in the face of outright tampering, the secrecy and security of the identification system should not be compromised.

Any electronic device such as a computer that ever reads any information from the outside world could possibly read information that is maliciously designed to subvert its regular functioning. Therefore, any computer that takes any input is vulnerable to attack and hence cannot be trusted.

A discussion about biometric authentication is not directly relevant, but may be important when trying to compare the merits of the proposed system.

In recent years there have been many achievements in the way of biometric devices. Biometric technology attempts to take some immutable physical characteristic of a person and represent it digitally for authentication. In all cases the resulting digital representation is equivalent to a password in its own right. The only difference is that a lost password can always be replaced, whereas a password derived from an immutable physical characteristic, once stolen, will compromise that person's capacity to authenticate himself for the rest of his natural life. That is, a person's fingerprint minutiae pattern or IRIS codec, unique unto them, cannot be replaced or reissued.

A biometric authentication system may be is insecure if it employs untrusted sensory devices. Unattended devices are usually easy to defraud because there need not be a real finger/hand/voice/face that the sensor is perceiving. Biometric authentication cannot work with fingerprints, facial recognition, or voice recognition because these are the most easily stolen and forged, and because there are too many false rejects using current technology.

Even manual photo ID authentication does not work well because an outdated, low-quality ID photo may look less like its owner than a quality picture of a similar looking person of the same sex and hairstyle. Iris recognition looks hopeful as it provides close to zero false rejects and false accepts. However the iris binary "codec" looks very similar for different extractions from the same person and therefore is even closer to a password than a fingerprint minutiae pattern.

Systems that use hand geometry also look hopeful, but cannot be used if the person is injured or handicapped. In short, no biometric device is as universal or reliable as a memorized password with a card.

Authentication systems that work in isolation (that is, between an institution and it's customers) provide little scope for interrelating personal profiles collected by other organizations. A trusted third party would collate data from many sources to provide more generic and flexible services. They would also provide the individual with anonymity and therefore, privacy as well as protection against exploitation by the institutions; and further providing the institution with protection against fraud both through reliable authentication and the proper use of shared data for tracking fraud schemes. The absence of a trusted third party isolates organizations and data, thus making it difficult to realize these kinds of benefits.

OBJECT OF THE INVENTION

It is an object of the invention to provide an authentication method and system.

SUMMARY OF THE INVENTION

An authentication method comprising the steps of: communicating a device to be authenticated with an authentication server station so that the server station transmits a first code; receiving the first code from the server station; entering the code manually on an manual input means on the device; transmitting a second code provided by the device in response to inputting the first code into the device, to the server station.

An authentication method including the step of limiting communication to a memory means of the device to the manual input means.

An authentication method including the step of allowing communication from the memory means to the server station or to the server station via a host device, through wireless communications and/or magnetic communications.

An authentication method including the step of using a remote terminal as a host to facilitate communication of the device with the server station.

An authentication method in which the host recognises the device as a device to be authenticated according to the method.

An authentication method in which the host facilitates communication between the device and the authentication server.

An authentication method in which a computing means in the device generates the second code in response to the inputting of the first code, by using the first code to obtain an address in an array of codes which address corresponds to the second code or which address contains information from which the second code is derived or computed.

An authentication method in which the first code as well as a user's PIN is entered into the device.

An authentication method in which the first code is encrypted as a function of the PIN.

An authentication method in which the encryption algorithm is specified by the server station or by the first code received from the server. An authentication method in which the second ^"code is derived from the first code.

An authentication method in which the first code indicates an address of information from which information the second code must be derived from or which information is the second code.

An authentication method including the step of receiving the first code in a discernible format.

An authentication method including the step of the first or second code indicating to a recipient thereof which encryption algorithm should be used for a subsequent transmission.

An authentication method in which the device is a card.

An authentication method in which the card is a bank card and includes a magnetic strip.

An authentication method in which the first code is encrypted as a function of a PIN or of a unique card identification number and is transmitted to the server station for verification of the PIN or of the unique card identification number.

An authentication method in which verification is possible as a result of the server station having specified to the device which encryption algorithm to use when encrypting the first code as a function of the PIN or the devices unique identification number.

An authentication method in which the second code or an encrypted second code is transmitted with an encrypted first code to the server station.

An authentication method the preceding claims in which ail previously used claims are flagged as being used. An authentication method in which the authentication server receives parts of a PIN for the device from two or more other servers.

An authentication method in which the parts of the PIN are encrypted when so received.

An authentication method in which an application is downloaded from the server to the card through a host device and all information for use of the application is entered on the device and encrypted on the device prior to transmitting the information to the server via the host.

An authentication method comprising the steps of: receiving, at a authentication server, notification from a remote station that a device to be authenticated is ready to receive a first code in an authentication process; transmitting the first code from the server station to the device via a host device for provision of the code to a user; receiving a second code from the device, the second code being derived from the first code by a memory means of the device in response to the manual entering of the first code by the user in a manual entering means of the device for transferring the first code to the memory means.

An authentication method including the step of limiting communication to the memory means of the device through the manual input means.

An authentication method including the step of allowing communication from the memory means to the server station or to the server station via the host device, through wireless communications and/or magnetic communications.

An authentication method including the step of using the host device to facilitate communication with the server station. An authentication method in which the host recognises the device as a device to be authenticated according to the method.

An authentication method in which the device generates the second code in response to the inputting of the first code, by using the first code to obtain an address in an array of information codes which address is the second code or which address contains information from which the second code is derived.

An authentication method in which the first code as well as the user's PIN is entered into the device.

An authentication method in which the encryption algorithm is specified by the server station or by the first code received from the server station.

An authentication method in which the second code is derived from the first code.

An authentication method in which the first code indicates an address of information from which information the second code is derived of or which information is the second code.

An authentication method including the step of displaying the first code in a discernible format at the host.

An authentication method including the step of the first or second code indicating to a recipient thereof which encryption algorithm should be used for a subsequent transmission. An authentication method in which the device is a card.

An authentication method in which the card includes a keypad.

An authentication method in which the first code is encrypted as a function of a PIN and is transmitted to the server station for verification of the PIN.

An authentication method in which verification is possible as a result of the server station having specified to the device which encryption algorithm to use when encrypting the first code as a function of the PIN.

An authentication method in which the second code is transmitted with an encrypted first code to the server station.

An authentication method in which all previously used claims are flagged as being used.

An authentication method in which the authentication server receives parts of a PIN for the device from two or more other servers.

An authentication method in which the parts of the PIN are encrypted.

An authentication method in which an application is downloaded from the server to the card through a host device and all information for use of he application is entered in the device and encrypted on the device prior to transmitting the information to the sen/er via the host.

An authentication system comprising: a server station for transmitting a first code to a host device upon receiving an alert signal that the host device is in communication with a device to be authenticated; a transmitter for transmitting a first code to be displayed at the host station for entering thereof by a user into a manual entering means on the device; and receiver means for receiving a second code from the device via the host, the second code being derived from the first code.

An authentication system comprising: a device connectable to a host and the host being arranged to recognise the device as a certain device to be authorized and to alert a server station that it is in communication with that device, a display means at the host for displaying a first code received from the server station, the device having manual input means for manually inputting the first code, and the device having communication means for transmitting a second code derived from the first code to the server station via the host.

An authentication system in which the device includes computing means.

An authentication system in which the only input means to the memory means of the device is the manual input means of the device.

An authentication system in which the communication means is wireless or magnetic communication means.

A device including a memory means for receiving information only from a manual input means associated with the card for use by computing means and/or storage on a memory means of the device.

The memory means transmits information through a wireless transmitter or through a magnetic communication means.

The device is a card.

An authentication method comprising the steps of: receiving, at an authentication server, notification from a remote station that a device to be authenticated is ready for communication and that the remote station wishes to facilitate such communication; The device sends the remote station the card's Encrypted Unique Identification Code which the remote station sends on to the authentication server;

The authentication server decrypts the card's unique identification number, and chooses a random first code which is an address correlating to that unique card identification number; The authentication server passes this first code to the remote station which is directly or indirectly passed to the device;

Furthermore an appropriate authentication server or servers pass an encrypted version of a secret PIN (Personal Identification Number), which is otherwise only known to the user of the device, to the remote station which in turn, passes it on to the device;

On correct entry by the user of the unique PIN into the device itself a second code is received from the device, the second code being derived from the first code by a memory means of the device in response to the manual entering of the first code by the user in a manual entering means of the device for transferring the first code to the memory means;

On the correct reception of the second code the authentication server verifies the user and the device and thereby informs the remote station of said authentication.

As base principles ensures that; the content of the arrays encapsulated in the device cannot be altered other than to be deleted;

The principles that the device being used for the authentication process must be upheld and adhered to since they are intrinsic to the overall success of the method and system and cannot be seen as being separate in any way.

Should they not adhere to this principle then they cannot be deemed suitable for this authentication solution.

That the authentication server is a trusted Third Party and the Trusted Third

Party cannot divulge any of the user's information or that system critical information encapsulated in the methodology illustrated in this document other than under special circumstances, a legal directive or under instruction of the user directly. Therefore the Trusted Third Party in its own right treats user information using the same principles in which the device treats the arrays. that the device can send information but cannot receive information other than through the pinpad as indicated above; cannot be altered in any fashion through any external device; the device takes no digital inputs whatsoever; cannot be accessed other than through the user prompting the device to act; Unless the device can comply with the above now or in the future then the method cannot be considered to be compliant;

Under ALL circumstances it is a base principle that the device never trusts any other device be it a host station, remote authentication server, or other, and similarly the authentication server never trusts the host station, the device or any other intermediary device. And neither the device or the authentication server trusts the user;

None of the unique information (of the 4 or more as indicated below) are stored on the device or in one place (except the arrays given that the random prompt for certain information in the arrays ensures secrecy); None of the unique information (of the 4 or more as indicated below) are stored on any singular server and/or the location of such information. Any information that is captured and stored irrespective of how well verified is considered to be data and therefore dead data. It is only the active use of the active use of the various individual sets of data and in specific combinations in realtime by a use interactively that ensures authenticity and validation of data, and this principle encapsulates the whole method and system All communications are encrypted.

Secret algorithms are used to manipulate critical data on the card on identification of tampering and the data is altered in such a way as to make such change unnoticeable to the tamperer.

These and other features of the invention are described in more detail below. BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention are described below, by way of example only, and with reference to the accompanying drawings in which:

Figure 1 shows a schematic front view of a card for use in one embodiment of the authentication system and method;

Figure2 shows a schematic rear view of the card of figure 1 ; and

Figure 3 shows a schematic diagram of one embodiment of the authentication system that facilitates use of the authentication method.

DETAILED DESCRIPTION OF THE DRAWINGS

With reference to the drawings, an authentication system is generally indicated by reference number 1.

The system includes server computers (2, 3 and 4) and an automatic teller machine (ATM) (6) all connectable to each other through a computer network (5).

Figures 1 and 2 show, respectively, front and rear views of a card (10) for use in the system. The card includes a keypad on one side and a magnetic strip on the other side. The card may be any one of the card embodiments or the card described in South African provisional patent application number 2003/9583. The card also includes memory means and computing means.

It is possible for the card to communicate with other electronic devices such as an ATM according to known standards, through use of the magnetic strip. The card also includes an on-board power supply.

However, in this case, when the card communicates with the ATM (as is known in the art) and thus also with an authentication server (4), through the magnetic strip, the ATM and/or server (4) recognizes the card as a card for use in the method described herein.

In its simplest form, authentication may happen as follows:

A client enters his/her card into an ATM. The ATM recognizes this card as one being used in the system according to this method. As a result, the ATM communicates with the server (4), alerting the server that it is in communication with a card to be authenticated, and receives a first code from the server (4) based on the card's unique identification number passed to it by the card.

This code must be entered into the card so that the card can return a second code associated or indicated by the first code, to the server, to authenticate the card. However, the code cannot be entered into the card by the ATM. The code can actually not be entered into the card in any electronic or magnetic manner. The only way the code can be entered into the card is manually by way of the keypad on the card. This means that the user must receive the code from the ATM in a discernible format. The ATM can display the code on its screen or print the code on its printer, for use by the user. The user now removes the card and manually enters the first code on the keypad of the card. The card is now again entered into the ATM where the card returns the second code through the ATM to the server 4. The code is verified by the server, and in this manner the card is authenticated.

One advantage of this method is that the storage space of the second codes are not accessible by the ATM or easily, by any other means as the array on the card cannot be interrogated through any electronic means. The bank of second codes is an array and each address in the array is indicated by the first codes. Preferably, each first code indicates one unique address in the array. The first codes may also be encrypted so that they must be decrypted by the card before they indicate the unique addresses. The second code is a code stored at the indicated address or any information taken from the unique address from which the second code is derived or computed. The second code may then be encrypted by the card prior to transmitting it via the ATM to the server 4.

To authenticate the user of the card, the following procedures may be followed:

The user may enter his/her PIN into the keypad on the ATM; or

The user may enter his/her PIN into the keypad on the card for the card to pass it to the server when the card is again entered into the ATM. The card may encrypt the PIN before passing it so on and the specific encryption technique (the word "technique" has the same meaning as the word "algorithm" herein) used may be as specified by the first or subsequent codes received from the server.

Altematively, The user must enter his/her PIN into the keypad on the card for the card to verify this PIN on the card. The stored PIN on the servers are never kept complete on any one server and the PIN parts are passed on to the card encrypted for verification to the manually entered PIN.

The above methods of authenticating the card and the user are also secure in that it prevents replays on the card of a plethora of first codes in an attempt to return a valid second code. The method allows for only one or few such attempt. Furthermore, once a second code has been received by the server (4), it may be marked as being used, to prevent re-use.

The array can also be a plurality of arrays. For example, one can be for use to verify the card and one to verify the user. One can be used to verify both card and user and the other as a spare for when to many failed/successful attacks have occurred on the other. It will be appreciated by those skilled in the art that a keyboard of a computer, a handset of a telephone or any other device can be authenticated in the same way as the card is authenticated in the method described above.

The ATM may also be replaced by any terminal or electronic device that may facilitate communication with the authentification server (4).

The ATM may further by replaced by a person such as a bank teller. The difficulty here is that such bank teller may display a wrong first code by mistake, or fraudulently. This is explained in more detail further below.

The bank teller receives a first code from the server (4) and shows it to the client.

The client enters this first code plus his/her PIN into the keypad on the card by removing the card from a card reader.

The card checks if the first code has not previously been used. If so, operation is discontinued. Otherwise, the card encrypts the first code and retrieves a second code from the array. The address of the second code is of course again dependant or indicated uniquely by the first code.

The card sends the encrypted first code and the second code to the server (4).

The server (4) verifies that its own copy of the second code is a match. If valid, the server (4) records the first code as being used. The server (4) also decrypts the encrypted first code, which was encrypted as a function of the PIN or card's unique identification number which may be entered by the client, to check that the decrypted first code matches the first code sent previously to the bank teller and shown to the client by the bank teller. The PIN is thus not transmitted in unencrypted form. The bank server (4) can check that the PIN is correct by decrypting the encrypted first code, which was encrypted as a function of the PIN, and because the server (4) has a copy of the PIN.

In another embodiment, the PIN is split between two servers (2 and 3) for added security. Encrypted parts of the PIN is obtained from the servers (2 and 3) decrypted by server (4) compared with the PIN, decrypted from the encrypted first code, verified and all records or memory relating to the PIN is then erased

The card may be tampered with and still provide no useful information. The only requirement with regard to tampering is that the tampering be detectable and will amend the contents of the card so as to make any information fraudulently obtain to be useless with making it obvious to the fraudulent party that such tampering was detected. If an attacker obtained the array and also sniffed the first code in transit, he would be able to deduce the second code by trying all 10000 keys (codes in the array) until he found one that produced the correct encrypted first code which was encrypted as a function of the PIN. Therefore, the card should be designed so that it is not possible to read the internal arrays through tampering without being detected. Note that technically, this is much more achievable than the more common requirement that a card be completely tamper proof.

The secure communication link to the server is required so that the bank (server (4)) is sure with whom it is communicating and also to ensure private communication as the authentication server as well as the card do not trust the ATM. This secure channel may be established using traditional means but customized per session.

In another example, consider a malicious bank teller, John, who displays a false value of the first code to a customer Mary. Mary transmits a valid encrypted first code and second code to the bank which is intercepted by John. To avoid suspicion, John always performs the proper operation on Mary's second attempt, claiming that Mary entered her key incorrectly the first time. After many such transactions, possibly requiring collaboration from other tellers, John has enough encrypted first code and second code pairs to create a custom card that has a statistically good chance of returning the correct value to the server for a particular random the first code.

Because the server does not advance the value of the first code unless second code is a match, John has only one attempt between each successful authentication of Mary. If John tries every day for a year, he only has to collect 30 pairs to be successful.

Further, because the card tags each the first code after use, Mary's card is just as likely to come across a used first code (and auto-disable) before John can be successful. If her card fails to work, Mary will procure a new card and this will arouse suspicion since the returned card can be analyzed and compared to the database. John will at least have to restart his collection. This attack is clearly a flaw in the system but requires John to cross several logistical hurdles. A denial of service attack that follows from this theme is that John can transmit a duplicate first code deliberately to cause Mary's card to auto-disable. However, as a denial of service attack this would arouse the most attention of all.

To improve security, an additional 4 digits can be used as a random challenge. However, the entering of 12 digits may be considered too inconvenient for the general public. A second "ultra-secure" version could work with a challenge, pin, and value of a first code of 5 digits each, totaling 15 digits.

Alternatively, inclusion of a time-stamping mechanism would require the card to keep time, and can be used instead of the additional challenge digits.

Both these mechanisms are suggested only to prevent the bank-teller attack discussed above. The easiest way to physically attack this system is to watch carefully when the user enters his pin, and then pick-pocket him later, hopefully managing to make a transaction before the card is reported stolen.

The point at which a user enters their pin is critical to the security of the system. This problem is alleviated, at least in part, by making it possible for the user to enter his or her pin on the card itself whilst the card is not physically connected to any equipment. The user may thus hold his or her card such that no one can see the actual pin entered.

The card never stores the user's PIN permanently. The pin is immediately encrypted and once the card communicated with the ATM or server or other equipment, the encrypted pin is transmitted without storing a copy of the pin or encrypted pin on the card.

A second reason to require that the first code be entered into the key-pad is that this forces random use of the keys. Should a card only ever have its own pin entered, the comprising digits will possibly be evident from fingerprints or wear. The entering of random digits with each authentication reduces this possibility.

The absence of a private key and the complex algorithms of public key cryptography means that the card requires minimal microprocessor resources. The SHA1-MAC algorithm is fast and light-weight and can be implemented with less expensive micro-controller devices.

The easiest way to hack the system appears to be the bank teller attack described above. If this attack is successful there is an extremely high likelihood of a misalignment between the range of first code values issued by the server, and the tagged first code values in the card. For example, both a customer and the bank may have sufficient logging at their disposal to resolve the dispute. The robustness of the logging trail still requires careful consideration however. Management of card hand-outs, cancellations, and claims of fraud is a complex logistical and sociological problem.

An example of the difficulty of the problem is the management of stolen card reports. If a card is reported stolen, should the card be disabled? Disabling a card because of a false claim of it being stolen is an example of a denial of service attack. How does the claimant prove he is the owner of a card that is lost or destroyed? 1% of credit cards are typically lost each year: what kind of infrastructure would be able to cope with tens of millions of these cards in circulation?

This highlights the benefits of placing an authentication service provider and trusted third party at the core of enrollment/the issuing of an authentication system. The user would have to revisit the authentication service provider / server of their choice and either undergo the full face-to-face procedures or alternatively provide specific information deemed necessary, for example, representing an identification document (ID) book without having to be re- fingerprinted etc., or whatever is deemed best practice by the server. This could take place in person or remotely in accordance with the globally accepted standards for face to face or other level procedures as specific to the authentication service providers service offering.

The availability to institutions of a server has many additional benefits that augment the advantages of reliable authentication.

Institutions that require collaboration of data can store their data with the server in association with the person's identity. For example, an insurance company can request that the date and type of recent claims be stored in the person's profile. An insurance company can be given the assurance that its customer database is secure from its competitors, but still allow competitors to test for simultaneous (and hence fraudulent) claims across different institutions. The most obvious example is that electronic voting can occur where the permission to vote is stored by the server. It would not be possible to vote twice in such a system because the server would remove permission from the user's profile and user's card profile after the first vote.

Another example is that a device/card holder can record his banking transfer limit with the server and require that the bank adhere to this limit. In the event of a dispute, the customer can call for the server's log of the transfer limit. This applies to ATM withdrawals, credit and debit card transactions, as well as electronic transfers such as Internet banking transactions. This will require that the transfer limit not be modifiable by the bank, but through an independent service or institution dedicated to that role. Hence, the control of the card holder's transfer limit rests outside of the bank, effectively providing refereeing of banking practice.

In addition, with regard to the "unbanked" and those wishing to use debit cards as electronic purses, the card can provide the additional cross-checks commonly provided by financial instruments/institutions. Rather than issuing smart cards loaded with electronic "cash'Yunits directly onto the card itself (thereby making the card vulnerable to tampering), a daily/monthly transfer limit and current card value can be stored with the server. This would also allow for users to manage the risk they assume when using the card.

PC keyboards can easily be manufactured to automatically type-out the card's Encrypted first code and Second code values in hexadecimal representation into a text input widget such as those in a web page form. Such a keyboard with a smart card slot would be trivial to manufacture. Once again, the system is immune to virus attacks because the card takes no input from the PC, but merely writes data into the keyboard.

The internals of a keyboard that would support such a card are far simpler than similar keyboards that try to be hosts for a regular smart card. Besides having to interface to the operating system, these cards talk smart card protocols both in reading and writing. Hence existing keyboards are likely to be more expensive than the keyboard proposed here.

The infrastructure changes to support web authentication are minimal. No client software need be installed on the PC whatsoever. Web pages with a tradition login and password phrase would be altered to display the n value, and accept the Encrypted first code and second code values as a 40 character (160-bit) hexadecimal string. The web server back-end performs the protocol exchange with the server.

Ordinary telephones manufactured to accept such a smart card can use DTMF tones to transmit the Encrypted first code and Second code values. There are 16 available DTMF tones requiring 40 digits (as with the hexadecimal string described above). DTMF tones can be transmitted as fast as 10 per second, requiring 4 seconds to transmit the authentication material.

Facilities for authentication over GSM networks are desirable considering the enormous number of cell phones in circulation, and the current trend toward banking authentication through SMS messaging. The proposed system can clearly be adapted as has the telephone handset and keyboard above. A separate device connecting to a cell phone could send the authentication data over regular GSM networks, or even using SMS messaging itself.

On the other hand, a smart card reader physically embedded in a cell phone may not be ergonomically practical. A smaller version of the smart card as a cell phone SIM card may be possible, however, once again, the danger would exist of the cell phone software being subverted. We can consider an electrical interface between the cell phone and the SIM card that allows the cell phone keypad to write keystrokes to the card. If the handset manufacturers can guarantee that the interface can only be controlled manually, and they can guarantee that the electrical interface cannot be read through the cell phone's software, (as well certifications being instituted to verify this) then the security would be sufficient. On the other hand, this may violate the principle of write-only and should be considered with caution over the alternative of a separate device.

Critical to the security of the card is the secrecy of the person's private 4-digit PIN. This secrecy should extend as far as possible, even through the process of issuing of the card. That is, the personal PIN and the card might be physically sealed together at the server center, and not known to the issuing teller. Ideally, the card and PIN would come as physical unit so that tampering would be evident. This would allow the infrastructure to be secure even in the face of fraudulent operators at the point of issue. (Notwithstanding any other security measures to be discussed in further documents.)

Revocation is a difficult problem. Any large-scale deployment would require an inordinate number of revocations due to lost, damaged, or stolen cards. Revocation would need to be immediate in order to disable a card that a person believes to be stolen. However a revocation that can be executed with impunity would create the opportunity to execute a denial-of-service attack against the system: To wit, John can greatly inconvenience Mary by calling in her card stolen without her knowledge or consent. At the other extreme, a revocation procedure that requires an authentication procedure that is as intensive as that required on initial issue of the card, would be prohibitively costly and not allow for immediate revocations. A compromise is explained as follows. Two policies options are discussed below, the latter is the only viable and practical option:

A complete revocation should be executable only through the same face-to- face authentication procedure required when issuing the card initially. However, the person may be able to temporarily disable his card through a 24-hour call center for a reasonable period (i.e. 36hrs). For example, John, having found his card stolen late on Saturday night, can phone the call center and go through random authentication steps based on personal information captured during initial face-to-face procedures and deemed sufficient to determine authenticity to a level of certainty. John then explains that he will fully revoke the card by Monday, upon which the card is disabled for the 36 hr time period. If the card is found, John simply ignores the deadline, and continues transacting thereafter. Such a policy is appealing because the call center is unable to activate cards, merely disable them, and then only for a finite time period. Putting minimal power in the hands of the call center would ensure that the infrastructure is not dependent on "trust" in call center operators.

The system is however not feasible because:

A person would have no way of reactivating their card prior to the chosen time period if the card is relocated - a common occurrence. It would be unacceptable for most people to not have access their funds for 36hrs. Lost cards would potentially constitute lost identity, again rendering them incapable of transacting or communicating for 36 hrs. A vast majority of users, particularly those in rural users would potentially find it difficult to revisit an issuing center within the 36hrs. Users would be forced to incur prohibitive additional costs in the event of a card being thought to be lost but then found Commercially, the above would put the card at a huge disadvantage in terms of adoption. The inconvenience to many would far out way the potential risk to a few, given the need for PIN activation irrespective of policy used

A permanent disabling of the card is possible through the call center, but the disabling can be reversed (i.e. the card re-activated) within a policy-chosen period of time - 24 to 36 hrs. The re-activation of a card will require the person make use of the card within the time period, or the card would be permanently revoked. This will allow for the commonplace scenario - a card is thought to be lost or stolen but then is found. A novel idea is that call centers, in addition to requiring responses based on personal data for authentication, should require the person recall a previous transaction on the card (one of the last three transactions made). When the card is used at the ATM, the card does not trust the ATM or the server (4).

When the card is inserted into a terminal (a terminal is any online communications device like, an ATM, a wireless ATM, a smart card reader or any wired, directly connected, or wireless device through which the card can communicate with the servers (2, 3 and 4). The card is either automatically or manual powered on by pushing a sequence of keys and/or through automated identification of a status change to the card due to the proximity of a terminal.

The card then will perform the necessary power-on-self-test to ensure correct operation and ensure that it has not been tampered with. Every card will be manufactured to be tamper proof as far as the application allows, i.e. no card can be completely tamper proof, therefore it is designed to discourage tampering due to the complexity require to compromise the card versus any value gained through this kind of fraudulent procedure.

The terminal identifies that this specific type of card (code name "Helix") has connected with it. From here on the terminal acts merely as a "un-trustworthy" communications gateway or as a "host" as also referred to herein. It may successfully authentication then allow for further transactions through the terminal as may be required but this will not always be the case.

The server (4) will pass a random unencrypted number to the card to specify an encoding technique and variant for use in the next step of the communication session.

The card will respond, via encrypted session according to this random number, and, in this instance pass the server its unique card number in encrypted form and request a PKI value (the second code (one of a number of codes in an array)) from a random chosen address by only giving the server (4) the PKI address. Based on the value of the PKI at this address the server will once again alter the encryption technique and request a PKI from a random address on the card.

The card will reply the appropriate address value with further encrypting the session (the value returned will affect the encryption technique when later privileged information is passed just to ensure a further level of security).

Now the card and the server trust each other implicitly, and the terminal is oblivious to the content of the communication session.

The PIN, which is not stored by the server is collected in parts from 2 or more additional servers (2 and 3) via two or more associated but different encryption techniques.

The card has now been authenticated but not the user.

When applicable, the base content, and the options available to the new card user are now downloaded to the card in much the same way as a Java applet within a browser which defines the framework of the new card users interaction with the Helix system and the possible services/transaction types and each transactions options and constraints - as much information is given so as to try and eliminate the possibility of the card having to be removed more than twice from the terminal as described below.

The new card user must now be authenticated by interact with the card after removing it from a terminal. The user then re-enters the card into the terminal to continue the transaction, i.e an online/offline secure authentication and transaction system) If biometric scanning is required via an onboard scanner on the card, then the information is passed to the card via the server in much the same way as the PIN.

The new card user is then prompted via the terminal or the card to remove the card from the terminal (the card and/or the server will communicate this with the terminal or the card). The new card user will then need to enter the correct PIN into the card with the card remover from the terminal, within a certain predetermined number of tries or time frame in order to proceed. (Same applies now to biometric information scanning as may be required). The entering of the PIN is thus done "off-line" with the card not connected to the terminal. The entered PIN is decrypted and compared with the PIN received by the card from the server (4), and decrypted by the card. If the PINS match, the user is positively identified. The PINS (Whether encrypted or decrypted) are now erased from the card memory. The PINS are never stored permanently on the card memory. The card thus receives the two PINs, one from the server and one from the user typed into the keypad on the card. The PIN received from the server (4) is encrypted and was received from two other servers, encrypted form, to be passed on to the card. The card, when it is removed from the terminal and in no communication with the terminal or any other device, decrypts the PIN received from the server (4) and compares it with the PIN received from the user while the card is still removed from the terminal and in communication with no electronic device. If the PINs compare, the user is authenticated and the card will now be used to conduct a transaction. Such transaction may be conducted in entirely format by encrypting each step in the communication process as follows:

The server (4) or the card sends a code to the other. Say the server (4) sends a code to the card, the card decrypted code points to an address in an array stored on the card. The address specifies a certain encryption technique. The card now encrypts information it wants to transmit to the server in accordance with this technique. The card also transmits a code for use by the server to know which encryption technique to use next. The server knows how to encrypt the message received fro the card because it knows which encryption technique is specified.

The server (4) decrypts the information and sends a reply message encrypted with the "new" encryption technique specified by the card.

The codes send between the server and card and randomly chosen. In the manner described above, the card and server can communicate in an encrypted manner.

Applications may also be downloaded to the card to, for example, conduct banking transactions and the like.

The new card user will choose from the various options available on the card (a downloaded application) and then return the card into the terminal when prompted via the screen on the card or when the required information has been entered as requested via a display on the terminal. This removal and reentry of the card into the terminal may be performed several times as may be required depending on the type of transactions required. It can thus be seen that the terminal only acts as a host - all information is entered on the keypad of the card.

At the end of the complete authentication session a "checksum" value is passed to the server by the various systems on the grid interacted with in order to build a session checksum which is once again communicated to by the card. If this checksum is correct then the whole session is certified and closed. Storage of the session will be kept with the associated keys multiple secure remote locations in order to decrypt the session at a later point in time as may be required by the nature of the transaction, 3^rd party verification services, or due to legal or other reasons.

A method and system is envisaged in order to ensure that the data is stored in multiple locations, in this instance a grid of servers such that compromise to any one part of the grid and/or the data in that section of the grid is useless without the data from the various other sections or part sections of the grid and that the data is scrambled within the various related other sections of the grid so as to re-establish the original compromised grid section but with a changed data set to as to make the originally compromised data to be useless even if the attacker managers to compromise a further related section of the grid.

Essentially the data become fluid whereby the to "grab" one section of the data changes the other sections instantaneously and randomly whereby the "shift" in the data structures are only known by the collective of uncompromised grid members.

It is essential that the level of authentication matches the risk of getting the authentication wrong. It is further very important that, given the high level of surity gained by the enrollment and issuing procedures, the system is not designed to block out every possible mismatch. Should this be the case then such mismatches when the authenticity of the user is valid could make the system unmanageable. In many cases it is appropriate to assume a certain level of risk in order to ensure appropriate and smooth operation of the application. If one does not do this then the user and the managers of the application will lose faith in the appropriateness of the system to the application and the system fails.

Sufficient logging and risk management can be done in order to ensure acceptable levels of losses, or authentication errors, occur without jeopardizing the effectiveness of the system/application.

The system will not compromise the life or well being of the user in life threatening situations such as forced "gun-to-the-head" and will allow the transaction to proceed unhindered.

Mechanisms will be put in place, as the case requires specifically during enrolment as indicated in the enrolment section above. This may include the registration of a 2^nd PIN or "panic" PIN. Using biometrics the user could use an alternative finger during a scan authentication to represent the panic scenario. For the first time issuing of cards a network of authorised issuing parties or enrollment partners will be established. Each of these issuing parties will agree to a "Program" that will require strict adherence to globally accepted best practice standards for "face to face" procedures for that particular population sector and usage e.g. government usage versus usage in a retail environment. They will also agree to ongoing surveillance of the (Enrollment Partners in order to minimize fraudulent issuing of cards. Any card issued by an Enrollment Partner will be immediately traceable to it's issuer allowing fraudulent issuing of cards to be detected and routed out.

On enrollment the new card user presents himself/herself to the Enrollment Partner in person. i) The new card user will be required to acknowledge that fraudulent identification could result in high penalties legally but could also result in possible life risking scenarios specifically if the card is used to identify the new card userjn circumstances of medical emergencies, ii) The new card user may be required to have his/her photo taken iii) The new card user may be required to give one or more samples of his/her signature iv) The new card user may be required to produce proof of his/her domicilium like a utility bill, pay slip, or the like v) The new card user may be required to have his/her biometric scan taken

The enrolment partner will take a blank unused card from stock. Each card is given a unique temporary stock number through a card reader which relates to the unique set of PKI's written to the card as a last stage prior to being released to enrolment partner outlets.

After this, the new card user will be required to remove the card from the card reader and enter their private PIN onto the keypad of the card (twice to ensure correct entry). The card will be re-entered into the card reader so that in accordance with the procedure described below, the necessary information will be forwarded to servers. It is envisaged that the card will act as the interface with the card reader to gather the information entered into the card reader by the enrolment partner and then the card would pass the information across to the servers (2 and 3) so as to protect the transfer of sensitive information at this critical stage.

The enrollment partner will perform the necessary scanning of documents, entry of new card user data, and confirmation and sign-off by the new card user that the information is current and correct. This sign-off document is also scanned for record purposes. All information gathered here is treated with the utmost privacy .

Further printable cosmetic customisation of the card is done on the card by the card reader such as name details, photo, bar codes, magnetic strip writing, and the like.

During a re-issue process, the above process would be followed exactly except that the old card would form part of the re-issuing process. The user would still be required to bring current documentation, like a utility bill, in order to ensure information is current, specifically domicilium. The rest of the process would be as above. The old card would be destroyed. In another embodiment, a cal center could be set-up for telephonic re-issue fo cards.

It is envisaged that re-issue of a card is not voluntary as cards expire after a predetermined time.

In use, should one do away with either the possibly two arrays of second codes (the "A" or "B" key arrays), say without a "A" array, there is no use of a pin and obviously no verification that the holder of the card is correct. Without the "B" array there is still verification of both the pin and the card, however, anyone claiming to be the holder of another person's card can try pin codes until the card is tagged as invalid. For example, consider that John has a grudge against Mary. John can go to the bank pretending to be Mary and try to authenticate himself with a forged card three times in succession. John will be denied access three times, but would have done the damage of invalidating Mary's card. Mary would then not be able to authenticate herself- -a denial of service attack— and therefore, both the "A" and "B" arrays are essential.

The same can be applied to the value the first code. Should the server tag and advance the value of the first code before verifying second code to be correct, it would allow John to endlessly try cards until all of Mary's n are consumed.

The use of once-off 64-bit keys means that, for example, even if a transaction is intercepted by a malicious bank teller, the information is of little use. The server will be sure to never request the same first code again. This also means that the card can only be used to authenticate a person 10000 times (the size of the array) before the entire array is exhausted.

If the card is stolen, only three attempts at key discovery are allowed before the card is invalidated. Therefore a brute force attack is not feasible.

The card/storage device, as well as the method, does not allow for any storage nor interaction by third parties with regard to user specific information and never in the area allocated to the authentication function i.e. the PKIs and the authentication process. The device only presents data. It may be that the card allows for other applications to run on the remaining memory e.g. E purse or encryption engines for generating communications sessions.

All active parties involved in any authentication session whether part of the TTP, enrollment partner, host station, or any other individual, entity, server or system are deemed untrusted and must go through secret authentication methodologies continuously the basis of which are described in the protocols. All session are only deemed secure for that session and then ALL parties are once again deemed to be untrusted.

Further that there are basically four pieces of unique information which are key to the system. These 4 (as listed below), but not limited to 4, are never handled, displayed, dealt with or in any way moved together so as to make vulnerable all together, but rather treated as separate checks to be performed in order to all be successfully completed in order to complete the authentication method. The four pieces of unique information are: The Arrays

The card's unique indentification number The users secret PIN

The numerical representation of the users biometrical scan However should it be necessary the system may choose to ignore inconsistencies in ALL checks barring the arrays and the secret PIN.

The secret PIN must always be physically entered into the device by the user. The selection of array variable must always be randomly selected by the authenticater.

The key the method and system is the embodiment of the communication and authentication methodologies. The basis of this is emobied in the Provisional however in refining our system and methodology it has become apparent that a minimum of three variance will be necessary for deployment based on user, usability and functionality as listed below. Please note that the reference to "device" below is only to illustrate the example described in our original provisional and extensions thereof as well as being materially achievable as we have a prototype, and needs to be stated that it would including any future embodiment of a device which has the base functionality to enable the method and system as illustrated. Protocol 1 amended (interactivity relying on a host station in the form of traditional devices such as ATM, smart cart terminal, etc). This is a device without a screen and biometric. This requirement is based on original provisional, i.e. a card with PINPAD. In addition the protocol amended below would also be applicable to a variant to the card previously described but including a biometrical scanner, and indicator for verification of inputs (pinpad and/or biometric) that enable non-reliance on host station.

The bank creates a secure communications link with the TTP and sends the TTP the card's unique identification number and thereby the TTP knowing that the request is genuine.

The customer provides the bank with his unique user profile number (not the PIN number but rather the unique user profile number selected at enrollment or his/her ID number and the like).

The bank sends the number over the secure link to the TTP.

The TTP looks up what card is currently in use by that person, and chooses a once-off random 4 digit number, n, which would previously never have been used to verify a pin (secret Personal Identification Number) for this card for this person. The TTP send n to the bank.

The bank displays n to the customer.

The customer enters into his keypad n, followed by his secret 4 digit PIN.

The card checks if the value of n has not previous been tagged as "used". If this check fails, then it permanently discontinues operation (or other as may be required). Otherwise, the smart card tags n as "used", computes H(n) = SHA1_MAC(A[n]) (first 96 bits), and sends to the bank the 64-bit key B[n] as well as H(n). It is noted that that complete PIN is never stored in one location (database) and the partial PIN is never stored in a manner linked to the user directly but rather to the card. Further more the arrays are stored randomly and requested randomly in separate secured servers in such a way that the arrays can be reconstitute on request. The TTP passes A[n] to the multiple servers holding partial segments of the pin. These servers then encrypt the partial pin segment/s (P(n) = SHA1_MAC(A[n],p) and send them to the card. The card then decrypts the partial pin segments, recostitues them in temporary memory, compares them to the pin entered by the user for verification, then erases the temporary memory on correct pin and informs the TTP of successful pin entered or not. The TTP may request reentry of the pin by the user as may be required.

The bank sends B[n] and H(n) to the TTP.

The TTP verifies that its own copy of B[n] is a match. This ensures that the card is indeed the card belonging to the person. A check is also done to see if the card has not previously been tagged as being invalid. If either test fails, then the TTP sends a negative response to the bank and performs no further action, neither does it issue a new n for the next authentication nor tag the current value of n as having been "used".

If the card is valid, then the TTP records n as being "used" to be sure of not issuing the same n in the future.

The TTP then computes SHA1_MAC(A[n]) and verifies that it matches H(n). This confirms that the person has a valid card If the computed value does not match, then the TTP records the failure. If there are more than three failures during a prescribed period of time, then the card is tagged as being invalid.

The TTP sends a positive or negative result to the bank.

Protocol 2, is where the only functionality on the card (including wireless techniques and other) removes the requirement for a host station as required above. The key amendments include a screen and a communications interface system as well as an alpha numeric keypad. It must be noted that the principle of write-only is upheld (as always) by any other functionality over and above authentication being treated as a hostile application. This protocol specifically deals with the ability to create secure tunnels, etc as described in previous correspondence. The ATM creates a secure communications link with the TTP and sends the TTP the card's unique identification number and thereby the TTP knowing that the request is genuine. The ATM recognizes version 2 protocol and verifies to the card and the TTP that it will act purely as a communications gateway and display device (keyboard entry option is possible for the entry of non-critical information as may be required).

The TTP establishes an encrypted session directly to the card inserted in the ATM and passes the communications processor n. The communications processor passes the array handler n. The array handler returns A[n].

The communications processor alters the encryption type to the TTP using A[n] as a variant, of which the TTP will "understand" due to the TTP expecting the encrypted session to use this variant, thereby positively identifying the card as being authentic. The card then uses 2 or more variances of the encrypted session using various privileged information in order to establish communications with two or more servers holding partial segments of the card's pin. The encrypted partial pin segments are then decrypted by the card and the segments are joined together in temporary memory and this pin is then compared to the pin entered by the user.

On verification of the pin the card then informs the TTP that the user has been authenticated.

Standard principles used in protocol 1 are used in this version as well.

Protocol 3. Where the Bluetooth or added wireless capacity results in a twin device. The key difference has to do with reporting. Also allows for multiple levels of authentication. Allows permissions and their operation in the community in general including updated requests, etc and where and how it is stored.

The substantial difference between protocol 2 and 3 relates to the following: Protocol 2 requires an online/offline (to allow it to be removed and re-inserted into the ATM) system while protocol 3 will use an elective online/offline system.

Methods of communication allow for peer to peer and third party application to client encrypted services including realtime type applications like voice communications.

Claims

1. An authentication method comprising the steps of: communicating a device to be authenticated with an authentication server station so that the server station transmits a first code; receiving the first code from the server station; entering the code manually on an manual input means on the device; transmitting a second code provided by the device in response to inputting the first code into the device, to the server station.

2. An authentication method as claimed in claim 1 , including the step of limiting communication to a memory means of the device to the manual input means.

3. An authentication method as claimed in any one of the preceding claims including the step of allowing communication from the memory means to the server station or to the server station via a host device, through wireless communications and/or magnetic communications.

4. An authentication method as claimed in any one of the preceding claims including the step of using a remote terminal as a host to facilitate communication of the device with the server station.

5. An authentication method as claimed in claim 4 in which the host recognises the device as a device to be authenticated according to the method.

6. An authentication method as claimed in claim 4 or 5 in which the host facilitates communication between the device and the authentication server.

7. An authentication method as claimed in any one of the preceding claims in which a computing means in the device generates the second code in response to the inputting of the first code, by using the first code to obtain an address in an array of codes which address corresponds to the second code or which address contains information from which the second code is derived or computed.

8. An authentication method as claimed in any one of the preceding claims in which the first code as well as a user's PIN is entered into the device.

9. An authentication method as claimed in claim 8 in which the first code is encrypted as a function of the PIN.

10. An authentication method as claimed in claim 8 or 9 in which the encryption algorithm is specified by the server station or by the first code received from the server.

11. An authentication method as claimed in claim 8 or 9 or 10 in which the second code is derived from the first code.

12. An authentication method as claimed in claim 11 in which the first code indicates an address of information from which information the second code must be derived from or which information is the second code.

13. An authentication method as claimed in any one of the preceding claims including the step of receiving the first code in a discernible format.

14. An authentication method as claimed in any one of the preceding claims including the step of the first or second code indicating to a recipient thereof which encryption algorithm should be used for a subsequent transmission.

15. An authentication method as claimed in any one of the preceding claims in which the device is a card.

16. An authentication method as claimed in claim 15 in which the card is a bank card and includes a magnetic strip.

17. An authentication method as claimed in any one of the preceding claims in which the first code is encrypted as a function of a PIN or of a unique card identification number and is transmitted to the server station for verification of the PIN or of the unique card identification number.

18. An authentication method as claimed in claim 17 in which verification is possible as a result of the server station having specified to the device which encryption algorithm to use when encrypting the first code as a function of the PIN or the devices unique identification number.

19. An authentication method as claimed in any one of the preceding claims in which the second code or an encrypted second code is transmitted with an encrypted first code to the server station.

20. An authentication method as claimed in any one of the preceding claims in which all previously used claims are flagged as being used.

21. An authentication method as claimed in any one of the preceding claims in which the authentication server receives parts of a PIN for the device from two or more other servers.

22. An authentication method as claimed in claim 21 in which the parts of the PIN are encrypted when so received.

23. An authentication method as claimed in any one of the preceding claims in which an application is downloaded from the server to the card through a host device and all information for use of the application is entered on the device and encrypted on the device prior to transmitting the information to the server via the host.

24. An authentication method comprising the steps of: receiving, at a authentication server, notification from a remote station that a device to be authenticated is ready to receive a first code in an authentication process; transmitting the first code from the server station to the device via a host device for provision of the code to a user; receiving a second code from the device, the second code being derived from the first code by a memory means of the device in response to the manual entering of the first code by the user in a manual entering means of the device for transferring the first code to the memory means.

25. An authentication method as claimed in claim 24, including the step of limiting communication to the memory means of the device through the manual input means.

26. An authentication method as claimed in any one of claims 24 to 25 including the step of allowing communication from the memory means to the server station or to the server station via the host device, through wireless communications and/or magnetic communications.

27. An authentication method as claimed in any one of claims 24 to 26 including the step of using the host device to facilitate communication with the server station.

28. An authentication method as claimed in claim 27 in which the host recognises the device as a device to be authenticated according to the method.

29. An authentication method as claimed in claim 24 or 28 in which the host facilitates communication between the device and the authentication server.

30. An authentication method as claimed in any one of claims 24 to 29 in which the device generates the second code in response to the inputting of the first code, by using the first code to obtain an address in an array of information codes which address is the second code or which address contains information from which the second code is derived.

31. An authentication method as claimed in any one of claims 24 to 30 in which the first code as well as the user's PIN is entered into the device.

32. An authentication method as claimed in claim 31 in which the first code is encrypted as a function of the PIN.

33. An authentication method as claimed in claim 31 or 32 in which the encryption algorithm is specified by the server station or by the first code received from the server station.

34. An authentication method as claimed in claim 31 or 32 or 33 in which the second code is derived from the first code.

35. An authentication method as claimed in claim 34 in which the first code indicates an address of information from which information the second code is derived of or which information is the second code.

36. An authentication method as claimed in any one of claims 24 to 25 including the step of displaying the first code in a discernible format at the host.

37. An authentication method as claimed in any one of claims 24 to 26 including the step of the first or second code indicating to a recipient thereof which encryption algorithm should be used for a subsequent transmission.

38. An authentication method as claimed in any one of claims 24 to 37 in which the device is a card.

39. An authentication method as claimed in claim 38 in which the card is a bank card and includes a magnetic strip.

40. An authentication method as claimed in any one of claims 38 to 39 in which the card includes a keypad.

41. An authentication method as claimed in any one of claims 24 to 40 in which the first code is encrypted as a function of a PIN and is transmitted to the server station for verification of the PIN.

42. An authentication method as claimed in claim 41 in which verification is possible as a result of the server station having specified to the device which encryption algorithm to use when encrypting the first code as a function of the PIN.

43. An authentication method as claimed in any one of claims 24 to 42 in which the second code is transmitted with an encrypted first code to the server station.

44. An authentication method as claimed in any one of claims 24 to 42 in which all previously used claims are flagged as being used.

45. An authentication method as claimed in any one of the preceding claims in which the authentication server receives parts of a PIN for the device from two or more other servers.

46. An authentication method as claimed in claim 45 in which the parts of the PIN are encrypted.

47. An authentication method as claimed in any one of the preceding claims in which an application is downloaded from the server to the card through a host device and all information for use of he application is entered in the device and encrypted on the device prior to transmitting the information to the server via the host.

48. An authentication system comprising: a server station for transmitting a first code to a host device upon receiving an alert signal that the host device is in communication with a device to be authenticated; a transmitter for transmitting a first code to be displayed at the host station for entering thereof by a user into a manual entering means on the device; and receiver means for receiving a second code from the device via the host, the second code being derived from the first code.

49. An authentication system comprising: a device connectable to a host and the host being arranged to recognise the device as a certain device to be authorized and to alert a server station that it is in communication with that device, a display means at the host for displaying a first code received from the server station, the device having manual input means for manually inputting the first code, and the device having communication means for transmitting a second code derived from the first code to the server station via the host.

50. An authentication system as claimed in claim 48 or 49 in which the device includes computing means.

51. An authentication system as claimed in any one of claims 48 to 50 in which the only input means to the memory means of the device is the manual input means of the device.

52. An authentication system as claimed in any one of claims 48 to 51 in which the communication means is wireless or magnetic communication means.

53. A device including a memory means for receiving information only from a manual input means associated with the card for use by computing means and/or storage on a memory means of the device.

54. A device as claimed in claim 53 in which the memory means transmits information through a wireless transmitter or through a magnetic communication means.

55. A device as claimed in any one of claim 53 or 54 in which the device is a card.

56. An authentication method comprising the steps of: receiving, at an authentication server, notification from a remote station that a device to be authenticated is ready for communication and that the remote station wishes to facilitate such communication; The device sends the remote station the card's Encrypted Unique Identification Code which the remote station sends on to the authentication server; The authentication server decrypts the card's unique identification number, and chooses a random first code which is an address correlating to that unique card identification number; The authentication server passes this first code to the remote station which is directly or indirectly passed to the device; Furthermore an appropriate authentication server or servers pass an encrypted version of a secret PIN (Personal Identification Number), which is otherwise only known to the user of the device, to the remote station which in turn, passes it on to the device; On correct entry by the user of the unique PIN into the device itself a second code is received from the device, the second code being derived from the first code by a memory means of the device in response to the manual entering of the first code by the user in a manual entering means of the device for transferring the first code to the memory means; On the correct reception of the second code the authentication server verifies the user and the device and thereby informs the remote station of said authentication.

57. A device as claimed above which as base principles ensures that; the content of the arrays encapsulated in the device cannot be altered other than to be deleted; The principles that the device being used for the authentication process must be upheld and adhered to since they are intrinsic to the overall success of the method and system and cannot be seen as being separate in any way. Should they not adhere to this principle then they cannot be deemed suitable for this authentication solution. That the authentication server is a trusted Third Party and the Trusted Third Party cannot divulge any of the user's information or that system critical information encapsulated in the methodology illustrated in this document other than under special circumstances, a legal directive or under instruction of the user directly. Therefore the Trusted Third Party in its own right treats user information using the same principles in which the device treats the arrays. that the device can send information but cannot receive information other than through the pinpad as indicated above; cannot be altered in any fashion through any external device; the device takes no digital inputs whatsoever; cannot be accessed other than through the user prompting the device to act;

Unless the device can comply with the above now or in the future then the method cannot be considered to be compliant; Under ALL circumstances it is a base principle that the device never trusts any other device be it a host station, remote authentication server, or other, and similarly the authentication server never trusts the host station, the device or any other intermediary device. And neither the device or the authentication server trusts the user; None of the unique information (of the 4 or more as indicated below) are stored on the device or in one place (except the arrays given that the random prompt for certain information in the arrays ensures secrecy); None of the unique information (of the 4 or more as indicated below) are stored on any singular server and/or the location of such information.

Any information that is captured and stored irrespective of how well verified is considered to be data and therefore dead data. It is only the active use of the active use of the various individual sets of data and in specific combinations in realtime by a use interactively that ensures authenticity and validation of data, and this principle encapsulates the whole method and system All communications are encrypted. Secret algorithms are used to manipulate critical data on the card on identification of tampering and the data is altered in such a way as to make such change unnoticeable to the tamperer.