WO2009027616A1

WO2009027616A1 - Differential mutual authentication

Info

Publication number: WO2009027616A1
Application number: PCT/GB2007/003238
Authority: WO
Inventors: Richard Mervyn Gardner
Original assignee: Richard Mervyn Gardner
Priority date: 2007-08-25
Filing date: 2007-08-25
Publication date: 2009-03-05

Abstract

In the field of user authentication, the present invention provides an integrated system for the mutual authentication of a system database and a registered user with a view to increasing the security of remote authentication and the prevention of 'phishing/man-in-the-middle' attacks, by one of several alternative means including Code matching, PIN verification, Image reproduction and recognition, Signature and personal data verification, DNA verification and Biometric verification, by means of the differential between Codes held at the database from data recorded for that user and from a single Code retrieved from a data carrying device issued to the user.

Description

DIFFERENTIAL MUTUAL AUTHENTICATION

FIELD OF THE INVENTION

The present invention concerns improvements in the field of the authentication of a system user (hereafter a "User") to a system Database or Internet Website (hereafter called for the sake of brevity and clarity but not by way of limitation a "Database") by the prevention of phishing and man-in-the- middle attacks, by the reverse authentication of the Database to the User, by the security of data both in transit and recorded, and as a means of enhancing and protecting any form of Biometric authentication by incorporation into an interoperable multi application authentication system without any reference to or effect on any proprietary Biometric algorithms.

In this Application, the word "Database" means both the actual system to which authentication is sought but also where the context admits the Master System itself and the operational function of the Master System which computes, receives and sends Codes, and which confirms or rejects an authentication attempt.

The claimed improvements are obtained from a system of authentication based upon the differential between a variety of Codes recorded on a Database and a Code on a data carrying device or Smartcard, hereafter called for the sake of brevity and clarity but not by way of limitation a "Datacard".

BACKGROUND TO THE INVENTION

There are in existence a considerable number of methods of authentication with a wide range of attributes, complexity, and cost, and there is also a wide variety of problems associated with them, some being of a general kind and some being specific to a particular means of authentication. By far the most used system at present is that in which subsequent to identifying him or her self (with "userID"), the User inputs a Password or Personal Identification Number (hereafter called for the sake of brevity and clarity but not by way of limitation a "PIN"), which, being recognised by the Database, is taken as authentication of the User. This system is the most widely used because of its simplicity, familiarity and effectiveness.

However, such a system does have significant security flaws and it is generally regarded as unsuitable for systems requiring a higher level of security, partly because of the ease with which most fixed PIN's (or at least Passwords) may be discovered and partly because of the increase in phishing and man-in- the-middle attacks (the former involving the obtaining of personal data from a system User by fraudulent means and the latter involving the interception of authentication Codes "in-the-middle" between a User and the Database for replay) in both cases then enabling the personal data or Codes to be used to fraudulently access the system Database.

Various attempts have been made to increase the security of the userID PIN system - for example, by changing the PIN regularly, having longer PIN's, alpha-numeric PIN's, or only using parts of the PIN - but the danger of phishing and man-in-the-middle attacks remain and indeed is perceptibly increasing. Another widespread and generally more secure (and certainly many times as expensive) system for the authentication of a remote User is that whereby a variable Code, generated by a token or device usually (but not necessarily) after the entry by the User of a conventional fixed PIN, is entered into a Terminal and sent to the Database where it is matched with a similar Code generated by an identical process and algorithm.

The main advantage of such a system is that it avoids phishing attacks and is generally considered more secure than userID/ PIN, but it does not necessarily prevent a real-time man-in-the-middle attack whereby the interceptor gains access to the Database in place of the User. An entirely different form of authentication involves the comparison of a Biometric feature of the User, captured at the time of the attempted authentication, with a template of the selected Biometric feature which has been registered with the Database or recorded on a Datacard. Such a Biometric system carries its own set of problems, including particularly the security of data recorded on the Database or Datacard and the security of data in transit. In addition, Biometric systems suffer from various unique problems, including failure to register, false acceptance and false rejection.

At present, there is no protection available against phishing attacks for userID/PIN systems except to state that personal data would never be solicited and to warn the User to be more cautious: and there is little protection generally against a man-in-the-middle attack since it is concerned with taking over access in a manner not readily ascertained, using rather than stealing data.

A man-in-the-middle attack is not in fact especially common as yet, is certainly no simple matter to arrange and has been aimed to date only at "higher value" systems. Perhaps for these reasons, most systems entirely ignore the possibility and would be vulnerable to such an attack, although its incidence seems to be slowly increasing.

It is a principal objective of the present invention to provide a regime which is immune to both phishing and man-in-the-middle attacks since no Codes (other than userID or identification data and random codes) are sent to the Database at all. This is achieved by means of a Code produced by the Database being sent to the User at a remote Terminal, where it is compared with a Code produced at the Terminal from the User's Datacard, to provide mutual authentication by one of several alternative means.

As secondary objectives, the present invention provides increased security of data, both in transit and recorded on a Database and Datacard, and also a means of enhancing and protecting any form of Biometric authentication by incorporation into an interoperable multi-application authentication system without any reference to or effect on any proprietary Biometric algorithms. SUMMARY OF THE INVENTION

The invention is as defined in the Claims

DETAILS OF THE INVENTION

Outline of the invention: interoperable mutual authentication

The present invention therefore proposes a simple and integrated system whereby the mutual authentication of a system User and the System itself may be achieved, by the sending of a Code from the Database to the Terminal where it is compared to a Code generated at the Terminal from the Datacard and from data input by the User.

Such a system may be used to enhance the simplest UserID and PIN system, to provide for various alternative means of authentication and also to provide a means of enhanced security and protection for a Biometric authentication system, all in a comprehensive interoperable system. Each of these alternative configurations may be achieved from the same Datacard having the same Code and using the same system, the difference being merely in the Codes sent from the Database. By this means both phishing and man-in-the-middle attacks are simply impossible since no data other than userID is sent to the Database so that there is nothing to intercept: and in fact no data other than random Codes are sent over insecure networks at all.

The system configuration will depend upon various factors, including the required level of security and terminal facilities available, but mutual authentication (of both the User and of the Database) could be achieved by any one of the following alternatives:-

[1] the Codes match without input from the User, providing verification of the Datacard (and of the Database) but not of the User - giving single factor authentication for very low security or a means to verify the Datacard itself

[2] the Codes match after the input of a Fixed PIN by the User, providing 2 factor userID/PIN authentication, but with increased security over a conventional system since the PIN is entirely self-set and not recorded either on the Datacard or at the Database

[3] the differential between the Codes (either with or without a User PIN input) generates onscreen a facial image representation of the User (which is not recorded on the Datacard or Database) for Terminal operator manual verification, providing 3 factor authentication

[4] as an alternative to [3] without using a PIN, the differential between the Codes generates a modified facial image onscreen together with other data such as a representation of the User's signature, the User's Postcode, date of birth or other data (none of which is recorded on either the Database or the Datacard) which is then compared with data supplied by the User (specimen signature, Postcode etc) prior to the receipt of the Code from the Database, thereby providing 3 factor authentication after Terminal operator manual verification [5] the differential between the Codes (optionally after the input of a Fixed PIN) generates the Template of a captured Biometric image of the

User (not recorded anywhere) which may be compared with an actual Biometric image of the User captured at the Terminal (after such actual image has been subjected to the same algorithm as was used for the template to provide comparable data), thereby providing strong 3 factor Biometric authentication

[6] by differential between the Codes generates the binary representation of the User's pre-recorded DNA matrix table, which can be checked against an actual DNA verification procedure in important and nonurgent cases, verifying beyond doubt that the Datacard was indeed issued to the person presenting the Datacard (or not as the case may be). [7] if and when a DNA sample may be extracted and a matrix template recovered in real time, the present invention provides a vehicle for direct DNA authentication, in that the relevant differential (the binary representation of the DNA matrix template taken at registration) will match the sample DNA matrix taken from the User at the authentication attempt in real time.

All of these alternative means of authentication are available from the one simple system, involving the comparison in the manner described below of the Code on the Datacard and that received from the Database, with significant advantages over existing systems or even combination of systems:

Phishing and man-in-the-middle attacks become simply impossible No sensitive data is recorded on the Database

No sensitive data is recorded on the Datacard and its loss is therefore a nuisance but not a security risk

Alternative means of authentication can be used for the same User in the same system for different purposes (e.g. PIN for a simple access but a Biometric for rights to amend data, or Image recognition where the Biometric reader at a Terminal was temporarily out of action) The PIN is not recorded on either the Database or the Datacard and is entirely User-set: it can therefore be re-set by the User after authentication by other means (e.g Image recognition, Biometric) without the need for a Helpdesk

The recognition of a facial Image or Signature could be either by Terminal operative (as described above for [3] or [4]) or the specimen Signature or Image captured at the Terminal could be treated as Biometrics and subjected to the same algorithm as produced the template revealed as the differential, and verified by conventional analogue comparison. Main elements of the invention

The main elements of the invention are all in common use (as explained in more detail at Fig. 1) and consist of a network of remote computer Terminals at which data is read from a User presented Datacard, and effectively compared with data held at the Database.

The present invention is based upon a Code of a length equal to that of the longest binary equivalent of the various forms of data required, such as a of a facial Image representation. Thus, if the binary value of an Image to be used is 20KB in length and other images (Biometric templates, DNA matrix, Signature and data image) are shorter, the Codes on the Database and the Code on the Datacard would each be 20KB in length.

The primary Code is a random Code generated for a new User called Code "C", and this would be recorded on the Datacard issued to the User.

The Codes recorded on the Database would in each case be the XOR of the binary value of data to be recorded and Code C.

The term "XOR" herein refers to the logic gate function Exclusive/ Or where two binary values (each of 0 or 1) are "compared with", "added to", or "differentiated from" each other, with the various XOR's (indicated here as "^Λ") possible for 0 and 1 being: 0 ^Λ 0 = 0 0 ^Λ l = l l ^Λ 0 = l l ^Λ l = 0 thus, the process is reversible, so that the differential of C and I = C^AI and the differential of C and C^ΛI = I.

Biometric authentication Authentication by Biometric verification of an actual, image capture reduced by the appropriate algorithm to a Session Template being compared against the Template revealed as the differential between two Codes would entail the following:

[a] the initial registration of Biometric data under controlled and secure circumstances [b] the conversion of this data to a Template format by means of an (possibly proprietary or secret) algorithm (not of itself a part of the claimed invention) to a binary value Code B

[c] the XOR of Code B with Code C to give C^ΛB stored at the Database [d] the capture of an actual Biometric reading at a Terminal

[e] the application to it of the same algorithm as employed at [b] above to provide a Session Template Code T

[f] the comparison of Code T with Code B (as revealed by the XOR of C^ΛB (from the Database) and C (from the Datacard) = B, with B not otherwise stored anywhere) to provide the basis for an analogue Accept/ Reject decision.

The particular and unique advantage of Biometric authentication is the ability to conduct, in respect of a proposed registrant or an actual user, a search against a database of persons already registered, and this would be available with the present invention just as in any other Biometric system. However the recorded Biometric data required for such a search would be kept separately and not be routinely accessed or required for authentication as such.

A proposed registrant would therefore be checked against a separate Database of users for duplication or for a match against wanted or indicated persons, and similarly the check could also be performed with an actual Biometric capture with the system in use, again precisely as with any other system but without the Biometric data being held on the Datacard or as above without it being routinely accessible at the Database.

Security of elements of the present invention

Since the Datacard carries no meaningful data, the loss of the card would present no security risk at all whilst its replacement would be at less cost than most similar Datacards or Smartcards and at a much less cost than code- generating tokens, and with none of the administrative costs involved in handling and distribution.

It is a particular feature of the present invention that no personal data is recorded at the Database or on the Datacard for the purposes of authentication and in fact the personal data need never be known at the Database at all (apart from the possibility of storing a Biometric template for future duplication checks), by the use of a further random Code N at registration, as explained in Figures 2 and 3.

If a fixed value is XOR' d with a random value, the outcome is a random value. Thus, R ^Λ F = R^ΛF which is a random number, and from which R may be recovered by the application of F ^Λ R^ΛF or F may be recovered by the application of R ^Λ R^ΛF. However, neither R nor F can be recovered directly from R^ΛF without knowing the other one, unless R was not truly random (only a pseudo-random) and (an important addition) the necessary time and skill is available to test what may be billions of possibilities to ascertain F: but if F is itself just a randomly generated number (although now "Fixed" and unchanging) this is at best more difficult and possibly becomes impossible.

The use of a Datacard is only essential for what might be called "Away" use: in a static situation for remote authentication, a programme on a user's computer would produce the necessary Code, although a Datacard (with a linked reader (the Datacard might be a USB token) might be preferred anyway.

DESCRIPTION OF THE DRAWINGS

Fig. 1 Description of the elements involved in the present invention

Fig. 2 Registration of system User, personal data values & Codes N and C

Fig. 3 Registration of Codes on Database

Fig. 4 Generation of short Code offsets & Registration of fixed PIN

Fig. 5 Codes on Database and Datacard after Registration Fig. 6 Authentication by Datacard without input Fig. 7 Authentication with fixed PIN

Fig. 8 Authentication by DNA profile

Fig. 9 Authentication by Image recognition

Fig. 10 Authentication by Signature or data recognition Fig.11 Authentication by Biometric capture verification

Fig. 12 Use of new random for each authentication

Fig. 1 is a diagram of the structural elements of the present invention, with a system User [1] having a Datacard [2] with a Memory or IC Chip [3] holding data. The User [1] and Datacard [2] are associated with both a personal computer and a number of remote Terminals [5], all equipped with a Datacard reader [6] and having one or more biometric capture devices [7], all linked [8] to a Database [9] which has recorded details of all Users and relevant Codes [10].

The Link [8] may be internal, a telephone, a wireless connection or the internet, and is assumed to be insecure.

The system is therefore suited to use at home or workplace as a comprehensive means or authentication to remote sites or databases, or as a means of authentication at remote Terminals whilst on business or personal travel. Fig. 2 shows the registration of a User [1], for whom a generated [20]

UserID [21] is recorded both on the Database [9] and sent to the Terminal [5] for recording on the Datacard [2]. Similarly, a generated [22] Code N [23] is recorded on both Database [9] and Datacard [2].

The generation [24] of Code C [25] takes place at the Terminal [5] and is recorded on the Datacard [20] only: it is not revealed at the Database at all.

At the Terminal [5], the Codes N [23] and C [25] are XOR'd together to provide Code N^ΛC [26] which is used to return Codes to the Database [9] for registration (shown at Fig. 3).

In addition, the registration of a facial Image (27), a User (1) specimen signature and other personal data (28) and one or more biometric capture templates (29) give binary values computed at the Terminal (5) and recorded temporarily for Image [30], specimen signature [31] and biometric template [32] (after registration, the temporary data values would be deleted).

There could be several different biometric registrations (such as 10 fingerprints, as is mooted for ID cards) and indeed several different forms of Biometric template, such as fingerprints, an iris scan and a palm vein scan. Clearly this would be preferable with open source systems: where a proprietary system were involved, the details of that system would remain secret and the present invention would operate in this regard merely as a carrier for that system. Generally, the present invention is not concerned with how a template is derived from a raw image capture, but merely to be able to process an image capture taken at an authentication in the same manner (whatever that might be) to provide an analogue comparison with the template.

The registration of personal data (image, signature, biometrics) clearly has to take place in secure circumstances, where the master system and Database [9] (or the remote Terminal [5] as agent for the Database [9] in registration) are as sure as can be that the images recorded do in fact relate to the person they think they are registering, especially since those images are never seen by or recorded at the Database [9]. Fig. 3 shows the computation of the final Codes to be sent to the Database

[9], being the XOR of Code N^ΛC [26] and each of the Codes for Image [30], Signature & data [31] and Biometric [32], which results in respectively N^ΛC^ΛI [33], N^ΛC^ΛS [34] and N^ΛC^ΛB [35]. These are sent [36] to the Database [9] where the XOR with each with Code N [23] gives the Codes to be recorded on the Database [9] of C^ΛI [37], C^ΛS [38] and C^ΛB [39].

It will be apparent, for example, that the differential between Code C^ΛI [37] on the Database [9] and Code C [25] on the Datacard [2] will be the value I [30] which can be converted to the Image of the User [I]: but the Database [9] has no record of that image and it is never passed through the Database [9]. The importance of the verification of data and the positive identification of the person being registered is of course paramount, but not peculiar to the present invention.

Fig. 4 shows the registration of data to deal with simplified authentication - either that of the Datacard [2] only or with User [1] and a fixed PIN. For these, clearly a code has to be held in common on both the Database [9] and the Datacard [2], and for this a part of Code C [25] indicated by an offset value "o" is used. A further offset "p" is also used to indicate where the PIN input is to be used.

The whole of Code C [25] is not used, as otherwise a rogue administrator of the Database [9] could ascertain the Image [30], Signature/ Data [31] and

Biometric [32] values, and it is a particular claim of the present invention that no data is recorded.

Thus, two offsets are generated [40], offsets o and p [41], and a PIN [43] is registered [42] . This is shown as 4 digits but it could be more, or indeed less. At offset "p" within offset "o" within Code C [25], the PIN values are differentiated [44] by XOR and the resultant Code Cop [45] is notified to the

Database [9]. The offset values o,p [41] are recorded on the Datacard [2] but not sent to or recorded by the Database [9].

If an actual DNA profile matrix is to be registered, a further offset "ά" [47] is generated [46], a DNA matrix C [49] is compiled from an actual specimen, converted into a binary code and again the values are differentiated [50] by XOR resulting in a Code cd^ΛD [51] being recorded at the Database [9].

Fig. 5 shows the Codes and data recorded on the Database [9] and the

Datacard [2] after registration. Both will carry the same ID [12], but otherwise there is no common data at all. The Database [9] will have: the Code for authentication by Datacard [2] only or with fixed PIN, Cop [45], the Code for DNA authentication cd^ΛD [51] the Code for the User [1] Image C^ΛI [37] the Code for Signature or other data C^ΛS [38] and the Biometric Code or Codes C^ΛB [39]

The Datacard [2] will have: the main Code C [25] the offsets for the position within Code C for the short code, and the offset within that offset for the PIN position p (part of o,p [41]) a separate offset for the position of the DNA matrix registration d [47]

It will be seen that the Database [9] has no recognisable data recorded on it and neither does the Datacard [2].

Fig. 6 shows authentication of the Datacard [2] but not of the presenter of that Datacard [2] (who may or may not be the User [I]). The o,p [41] is applied to the Code C [25] to produce a Code Co [61] (not recorded as such on the

Datacard [2] but readily derived from it). The Database [9] sends [62] the Code

Cop [45] to the Datacard [2] where it is compared [63] with Co [61]. Assuming the fixed PIN to be 4 characters in length, the two Codes Co [61] and Cop [45] will differ by 4 digits only, which is acceptable: if the difference were greater, this would not be accepted. What the differences might be is not known or relevant.

Fig. 7 shows authentication of the User [1] with a fixed PIN. The Code Co [61] is derived and the fixed PIN [43] entered into the terminal [5] linked to the Datacard [2]. The XOR offset p [41] is then determined [71] and the fixed PIN value [43] is XOR'd [72] to Co [61] at the position p [41] to give a value Cop [51]. The Database [9] sends [75] to the Datacard [2] its Code relative to PIN authentication Cop [45] which is then compared [76] with Cop [51] and found to be identical [77] (or not as the case may be) Fig. 8 shows the authentication of the presenter of the Datacard [2] by

DNA profile, presently in important cases but possibly in future as a routine matter in real time.

The offset d [47] is applied to Code C [25] and a DNA specimen is provided and analysed at D [81], XOR'd together [82] with the offset to provide cd^ΛD [83]. This is then compared [85] with Code cd^ΛD [51] received [84] from the Database [9] to determine whether or not they are the same.

Fig. 9 shows authentication by image recognition at the Terminal [5]. The

Database [9] sends [91] the Code C^ΛI [37] to the Terminal [5] where it is differentiated [92] with Code C [25] to produce the Image [93] value which is then shown onscreen (converted to a jpg image or similar) for operator verification or refusal.

Fig. 10 shows authentication by specimen signature or data production. The Code C^ΛS [38] is received [101] from the Database [9] and XOR'd [102} against Code C [25] to produce an image S [103], which may be compared [105] with the User input [104] for acceptance or rejection. Obviously the User input [104] is selected and required from the User [1] before the Code C^ΛS [38] has been processed.

Fig. 11 shows authentication by conventional biometric verification, overlaid on the system of the present invention.

Code C^ΛB [39] is sent [111] from the Database [9] to the Terminal [5] where is it differentiated [112] with Code C [25] to produce B [113], the binary value of a Biometric template.

At the Terminal [5] the User [1] presents a Biometric feature for capture [114] at the Biometric reader [7] which is then subjected to the relevant algorithm to provide a Session Template [115]. The two values, B [113] and

Session template [115] are then compared on an analogue basis leading to

Acceptance or Rejection [116].

The settings for the Biometric system overlaid on the present invention may be rather "course" since authentication by additional means is readily available. In other words, it could be made to be virtually impossible to have a False Rejection, and indeed actually impossible to have a False Acceptance.

Fig. 12 shows how a random number can be used to further disguise the

Codes sent from the Database [9] to the Datacard [2] at the Terminal [5]. This not actually necessary since the interception of any of the Codes from the Database [9] would reveal only a random code which could not be used for any illicit purpose. Specifically it could not be used to fabricate a working fake datacard which worked across the whole spectrum of means of authentication, although it might be used to make a fake datacard, by the XOR of the code received (whatever it was, the interceptor would not know) of say an Image of the interceptor, although the difficulties of matching this with an acceptable ID appear insurmountable. Certainly phishing as such remains impossible.

With a high value system, or where higher security levels were required, the use of the additional random on each occasion of use would be indicated. Code N [23] could be used, by rotating the elements around an offset value, either fixed or determined by a date/ time formula, known to both Database [9] and Datacard [2].

Alternatively, a new Random R [122] could be used on each occasion which would be XOR'd [123] onto the code (e.g. C^ΛI [37]) sent [125] by the Database [9] to the Datacard [2]. Separately, the Random R [122] at the Datacard [2] would be XOR'd [126] with Code C [25] to provide R^ΛC [127]. Finally, the XOR of R^ΛC^ΛI [124] and R^ΛC [127] would again produce the Image [128] value. The Random R could be obtained from one of the following means:

[a] generated at the Datacard [2] and sent [121] to the Database [9] with UserID [21]

[b] it could be the last code used at the particular terminal [5] being used for this authentication, known to both

[c] it could be a sequential Code, being the last Code used by the User [1] which would incorporate Code N in the first authentication, to be discarded by subsequent sequential values.

CONCLUSION

The Codes used in the present invention tends towards (in the mathematical sense) a Vernam Cipher or One Time Pad ("OTP"), eventually approaching (if not reaching) that state for which Claude Shannon in 1949 proved that because of the randomness involved, the value of any one element of a OTP gave no clue at all as to the value of any other element, and therefore a Code based upon a OTP used only once was absolutely secure against decryption. Although the OTP concerned the field of secure messages, the principles involved are the same.

The proposed invention is therefore an integrated interoperable system of mutual authentication using essentially random codes with the advantages claimed in this Description and with the potential to deal with real time DNA profiling.

Claims

I claim:

1 A system for the authentication of a registrant issued with a data carrying device recording identification data and a random code wherein subsequent to the introduction by the registrant of the data carrying device at a device reading apparatus connected to the system and the sending of said identification data to the system, the system sends, from recorded data related to the registrant a code to the device reading apparatus which is compared with the random code thereby providing for mutual authentication of the system and the registrant by reference to a preset differential between the two codes.

2. The system of Claim 1 wherein the differential is within a specified range of values.

3. The system of Claim 1 wherein the differential is equal to the value of a personal identification number known to the registrant such that after entry at the data reading device of the correct personal identification number the differential is zero.

4. The system of Claim 1 wherein the differential is equal to the binary value of a password known to the registrant such that after entry at the data reading device of the correct password the differential is zero

5 The system of Claim 1 wherein the differential comprises the binary value of a facial representation of the registrant which is displayed at the device reading apparatus for comparison with the person presenting the data carrying device, thereby providing for mutual authentication of system and that person.

6 The system of Claim 1 wherein the differential comprises the binary value of a representation of the registrant's signature, which is displayed at the device reading apparatus for comparison with a specimen signature provided by that person, thereby providing for mutual authentication of system and that person.

7 The system of Claim 1 wherein the differential comprises the binary value of a representation of other personal data related to the registrant, which is displayed at the device reading apparatus for verification against personal data disclosed by that person, thereby providing for mutual authentication of system and that person.

8 The system of Claim 1 wherein the differential comprises the binary value of a Biometric template of the registrant which is compared with a template derived from an actual Biometric image capture taken at the time of the attempted authentication by a Biometric capture device linked to the device reading apparatus, thereby providing for mutual authentication of system and that person by conventional Biometric verification.

9. The system of Claim 1 wherein the differential comprises the binary value of a pre-registered DNA matrix template of the registrant, such that on entering the binary value of a DNA matrix template recorded at the time of the attempted authentication the differential is zero, thereby providing for mutual authentication of system and that person by reference to that persons DNA.