GB2492050A

GB2492050A - One-time multi-factor biometric representation for remote client authentication

Info

Publication number: GB2492050A
Application number: GB1109832.4A
Authority: GB
Inventors: Torben Kuseler; Hisham Al-Assam; Ihsan Alshahib Lami
Original assignee: Individual
Current assignee: Individual
Priority date: 2011-06-13
Filing date: 2011-06-13
Publication date: 2012-12-26
Also published as: GB201109832D0

Abstract

In remote mobile handset 140, fresh biometric 120 and personal identification 145 data of client 110 is combined with real-time geographical location and current time from source 115 to form one-time multi-factor biometric representation (OTMFBR) 150. The OTMFBR is used in remote authentication of the client to an authenticator (185, fig. 1) for performing transactions via connection 160, preferably wirelessly. The authentication is based on two independent sources of real-time and current location obtained separately at the client (e.g. from GPS receiver 125) and at the authenticator (e.g. from cellular network 190, fig. 1). The current time is used to stamp the OTMFBR to guarantee a one-time property of authentication message 155 to prevent replay attacks, whilst the location is used to authenticate the physical position of the client. The biometric data may be generated from a facial image obtained from integrated camera 130 or it may be generated using any other biometric sensor(s) or combinations thereof, e.g. iris, fingerprint, voice or handwriting.

Description

t V.' INTELLECTUAL ..* PROPERTY OFFICE Application No. GB 1109832.4 RIM Date:12 October 2011 The following terms are registered trademarks and should be read as such wherever they occur in this document: Wi-Fi Intellectual Properly Office is an operating name of the Patent Office www.ipo.gov.uk One Time Multi Factor Biometric Representation (OTMFBR) for remote client authentication

Field of the Invention

The embodiments of this invention relate to an authentication system between a client and any business institution or certification authority. In particular, the embodiments relate to remote wireless or wired authentication schemes based on sensors available onboard the client's mobile-handset that shall be used to relay the client's biometrics, fresh personal identification data (PIN, password, token etc.), and current geographic location in real time in a format of a single binary representation.

Background of the Invention

All mCommerce activities conducted from mobile-handsets require a participant/user/client to authenticate their identity for this purchase, financial transaction or contract. For example, a client making a financial transaction via his/her own bank. Conventionally, the user will be known to the bank and he/she produces a passport or driver's license as identification during a face to face transaction.

However, nowadays transactions are made from client's mobile-handsets and the face to face identification is lost (no "where" and "when"). Biometric as well as PIN, password, token based identifiers are used to identify the person (the "who"). However, Biometric and PIN, password, token data can be stolen and impersonated/guessed, which makes the authentication process inconclusive, especially for non-repudiation.

Hackers and criminals exploit this void. In a live remote transaction, such criminals may fake any genuine person' s biometric and numerical identifiers (PIN, password, token etc.) by using images, replay attacks, "man in the middle" attacks or any other technique.

Furthermore, this criminal could be sitting at any remote unruly location outside the local law jurisdictions.

The use of biometric sensor technology for a person's identification does overcome some of the shortcomings of the remote authentication process. Some businesses already use these biometric sensors to enrol their clients, so to compare/authenticate their client database records with that supplied by the client during a remote financial transaction. However, such authentication is open for misrepresentation and can introduce further problems such as violating privacy. Most importantly, such authentication lacks the capability to ensure the location of the client or ensure that the fresh client biometric data is based on real-time activity.

Thus, there is a need for combining biometric authentication with other methods of identification such as personal PiN, password, token or location and real-time to enhance security of remote commerce transactions.

Summary of the Invention

On the client mobile-handset, embodiment of the invention comprises: a camera as biometric sensor means integrated into said mobile-handset to capture the client's face; a GPS receiver as a geographic locator that is integrated into said mobile-handset to allow a client's location, in combination with the client identifiers, to be used for authentication; means for generating, via said mobile-handset, a multi-factor biometric representation of that client; and wireless or wired communication means such as GSM, 3G, Wi-Fi, operable to send the authentication data-message to the authenticator using a secure communication protocol.

A system embodiment of this invention comprises: a mobile-handset; at least one biometric sensor integrated into said mobile-handset; a certification authority that host databases including the client's enrolled and stored biometric data, personal identification data, such as PIN, password, token; and verification means operable to authenticate a user's identification data acquired by said biometric sensors, GPS receiver, and other personal identifiers to match the user's stored authentication data at the certification authority.

The method embodiment of this invention comprises: acquiring biometric data of a client via a mobile-handset used by the client; acquiring location of a client and current time data via a mobile-handset used by the client; generating a One Time Multi Factor Biometric Representation (OTMFBR) consisting of the acquired data as well as the personal identification data; sending the OTMFBR to the certification authority via a secure communication channel; authenticating the received client's biometric data, time, location and other personal identification data to match the same client's stored biometric data, personal identification data, actual location of the user and time; and finally authorising the transaction when all authentication has been passed.

Other distinctions, embodiments and characteristics of this invention will become evident from the following detailed description, drawings and claims.

Brief description of the drawings

Fig. i illustrates a general scheme of this remote authentication process between a client and a certification authority (authenticator); Fig. 2 illustrates a block diagram describing the first scheme for the remote authentication process of Fig. 1 as a first embodiment of the present invention; Fig. 3 illustrates a block diagram describing the second scheme for the remote authentication process of Fig. 1 as a second embodiment of the present invention; Fig. 4 illustrates a block diagram describing the third scheme for the remote authentication process of Fig. 1 as a third embodiment of the present invention; Fig. 5 illustrates a block diagram describing a method of location binarisation that is required in the third scheme as illustrated in Fig. 4;

Detailed Description

The following description is based on specific functional components and processing steps based on the software and hardware implemented on a Smartphone mobile-handset at the client side, and on similar functional components and reverse processing steps performed on software and hardware at the authenticator side. However, this invention can be described in terms of similar functional components and various processing steps, including software and hardware, configured to perform these functions. Similarly, the embodiments of this invention may be practised on mobile-handsets and/or other devices, hardware and software and/or other authenticator sides hardware and software authentication activities of various types and purposes. Therefore, tailoring or altering or adding further modifications to this invention and its embodiments for any other authentication applications can be performed by skilled professionals, but should be considered as within the scope of this invention claims.

In the general authentication scheme of Fig. 1, reference numeral 100, at the client side 105, the remote mobile-handset 140 of the client 110 includes an integrated camera 130 to capture the clients face to generate the biometric vector in this embodiment. This biometric vector can also be generated from captured client's iris, fingerprint, voice or handwritten-signature from other biometric sensors on the mobile-handset and should be included as embodiments of this invention. Furthermore, this biometric vector can be generated from a combination of the captured client's biometric features to provide a stronger security for the authentication process and should be included as embodiments of this invention. This includes future sensors in biometric data capturing that may become available on the mobile-handset.

This invention uses the onboard GPS receiver 125 to capture real-time GPS signals from satellites 115 to produce accurate GPS time and geographical location coordinates of the client's mobile-handset, as per the principals of the GPS technology. Other embodiments of this invention may include the use of other geographical positioning techniques such as cellular or Wi-Fi positioning that may be available on the mobile-handset and offer the current location and time of this mobile-handset. This includes future time and location determination methods that may become available on the mobile-handset.

The mobile-handset 140 has input functions and sensors 135 to capture the client's textual, audio, visual and/or handwritten identification data, such as PIN, password, token, signature or voice. This includes future user identification and capturing methods that may become available on the mobile-handset.

The authentication process on the client side 105 starts by capturing the client's biometric features 120, the actual time and location using the GPS receiver 125 and the client's personal identification data 145 to generate the message 155 using message generation algorithm 150 that will be send to the authenticator side 170 via a secure wireless communication connection 160.

Also, shown in Fig 1., at the authenticator side 170, the authenticator 185, upon receiving the message 155, decodes the client's message 155 to identify the client 110 and the data of the message. The, the authenticator shall retrieve the client's pre-enrolled and stored biometric templates 175, the client' stored personal identification data 180 and the client's pre-agreed and stored areas of operation 182 from their databases. The authenticator 185 then contacts an independent localisation source, such as cellular network operators 190, to determine the client's location and current time. Finally, the authenticator 185 compares all this data to authenticate the client. Once the client is accepted 198 the transaction will be progressed, otherwise the transaction is denied 195.

Independently comparing the received client's GPS location with that obtained from the cellular network operator, serving the client's mobile-handset cellular network offers extra layer of authentication as embodiment of this invention. Other embodiments of this invention may include the use of other independent sources of authentication data that can be used to authenticate the client.

Fig 2. shows a block diagram illustrating the first scheme of utilising the general authentication scheme 100, reference numeral 200. At the authenticator side 170 of embodiment 200, the client's biometric template 175, client's personal identifiers 180 and areas of operation 182 are enrolled with the authenticator 185 and stored in their databases.

Once enrolled, the client is thereafter free to use this authentication scheme.

On the client side 170 this authentication embodiment 200 starts by collecting fresh biometric sample 210 of the client 110, and the biometric feature vector (BFV) is extracted 212.

Concurrently, time and location (T&L) information 202 are obtained from the mobile-handset onboard GPS receiver 125. A copy of this fresh T&L 202 is then crypto-hashed 205 to produce a shuffling key. The personal identifier based shuffling (PBS) algorithm 215 uses the crypto-hashed key to shuffle the BVF 212. The output is then transformed into a secure domain by employing user-based random projection 217. This algorithm combines personal identifier 207 with the shuffled key 215 to produce an OTMFBR 220 of the client at that specific time and location. Another copy of the fresh T&L 202 is then attached to the OTMFBRc 220 to produce the final authentication message 220 that is sent as part of the communication message 155 to the authenticator 185 via a secure wireless or wired communication link 160.

At the authenticator side 170, this embodiment 200 of this invention starts by decoding the received message 155. The T&L 232 and OTMFBR 245 are then extracted from the decoded message 225. As a first step, the process ensures that the client's mobile-handset claimed location is within the pre-agreed area of operation 227 based on the stored operational area database 182. If passed, the authenticator 185 requests 235 the current position 247 of the client's mobile-handset 140 directly from the client's cellular network operator 190 to independently verify that the mobile-handset is actually at the claimed location 250, i.e. within a pre-defined threshold. The authenticator 185 will then use its stored information of the client (the enrolled biometric template 175, the password/PIN hash value 180) as well as the crypto-hashed 240 T&L information 232 from the received message 225 to generate a fresh local OTMFBRA 265. This is then compared 270 with the received OTMFBRc 245 to verify that the client 110 is genuine. If the comparison result is within a certain pre-defined threshold, the authentication request is consider as authentic 198, otherwise as not authentic 195.

Fig 3. shows a block diagram illustrating the second scheme of utilising the general authentication scheme 100, reference numeral 300. At the authenticator side 170 of this

S

embodiment 300, the client's cancellable biometric template 345, client's personal identifiers and areas of operation 182 are enrolled with the authenticator 185 and stored in their databases. Once enrolled, the client is thereafter free to use this authentication scheme.

On the client side 105, this authentication embodiment 300 starts by obtaining live GPS T&Lc data 302 via the mobile-handset onboard GPS receiver 125. This T&Lc data is then converted to binary 305. The resultant concatenated binary representation of T&Lc is then shuffled 307 by a shuffling key coming from personal identification data 325. The output code of 307 is then encoded using an error correcting code (ECC) algorithm 310. This ECC algorithm is used to eliminate the effect of the noise of the biometric data, which allows the authenticator 185 to retrieve T&L 367 captured at the client side 105 from the OTMFBR data message 315. Concurrently to collecting a T&Lc, a real-time, fresh biometric sample 335 of the client 110 is captured by the mobile-handset sensor 130. After extracting the client's BVF 340, this embodiment includes the user-based random projection algorithm 330 followed by a biometric binarisation algorithm 320 to produce a "Cancellable Biometric Binary Representation" (CBBR) 317 of the client. When the output of the ECC encoder 310 and the CBBR data 317 are generated, an XOR function 312 is used on this data to generate the OTMFBR 315 that is then sent as part of the communication message 155 to the authenticator 185 via a secure wireless or wired communication link 160.

At the authenticator side 170, the embodiment 300 of this invention starts by decoding the received message 155. The stored cancellable binary biometric template 345 is retrieved and XORed 347 with the received OTMFBR 342 extracted from the decoded message 155. The output is then fed to a local ECC decoding (reverse algorithm of the ECC encoding algorithm 310) algorithm 350 to correct the bits resulting from the difference between the enrolled/stored 345 and the freshly captured biometric samples 335. If the difference is larger than a pre-defined threshold, the authenticator 185 will reject the authentication process 195.

However, if the biometric verification 357 is passed, then the inverse shuffling 362 based on the stored shuffling key 180 is applied on this data to re-produce the binary representation of the GPS T&L 367. This binary representation is then converted back to its original decimal representation by a binary to decimal conversion algorithm 365. This scheme embodiment also checks the liveliness 370 of the received OTMFBR 342 by comparing the message GPS time 367 with current time. If the difference between the two times is greater than a pre-defined period of time, the authentication attempt will be considered as a "replay attack" and will be rejected 195. This scheme proceeds with verifying the received GPS position Lc 367 with a position of the client 110 independently obtain from the cellular network operator 190.

Finally, if the test 375 that Lc is inside the pre-agreed operational areas 182 succeeds and the distance between L and LA is within a specific range 385, then the authentication attempt is approved 197, otherwise rejected 195.

Fig 4. shows a block diagram illustrating the third scheme of utilising the general authentication scheme 100, reference numeral 400. At the authenticator side 170 of this embodiment 400, the client's cancellable biometric template 470, client's personal identifiers 180, areas of operation 182, and a key based on the mobile-handset (Keyph0) 469 are enrolled with the authenticator 185 and stored in their databases. Once enrolled, the client is thereafter free to use this authentication scheme.

At the client side 105, this authentication embodiment 400 starts by obtaining live GPS T&Lc data 410 via the mobile-handset onboard GPS receiver 125. A binary representation is then produced using a location binarisation algorithm 412. This L binary representation is then fed into a PBS 415 with a personal identifier based shuffling key 407. Equally, the time Tc 432 of the received GPS message 410 is converted to binary by simple decimal to binary conversion 435, and then XORed 437 with the Keyphone 440, which is then encoded by ECC1 algorithm 427 to tolerate the difference between the binary representations of the used locations. The ECC1 encoding algorithm output is then XORed 417 with the shuffled binary representation of L. The result is then input to ECC2 algorithm 420 to deal with the variations of the biometric samples. Finally, the ECC2 algorithm output is XORed 422 with the freshly calculated cancellable biometric binary representation 430 (obtained from real-time biometric sample 450 in the same way as explained in embodiment 300) to produce the final OTMFBR 425, that is then sent as part of the communication message 155 to the authenticator 185 via a secure wireless or wired communication link 160.

At the authenticator side 170, this embodiment 400 of this invention starts by decoding the received message 155. The received OTMFBR 455 is then XORed 457 with the stored cancellable biometric binary template 470. The data is then decoded by ECC2 (reverse algorithm of the ECC2 encoding algorithm 420) algorithm 459. If the ECC2 decoding algorithm does not succeed, the request is considered as not authentic 195.Successful ECC2 decoding 460 means that authentication has passed the biometric test and that the user-based random projection key 407, used by the client, is authentic. If this decoding succeeds 460, client's location LA is then independently obtained 485 via cellular networks operators 190, and a binary representation of LA is generated 477 using the LocBinarisation algorithm 500 and then shuffled 472 with the enrolled shuffling key 180. The binarised LA 475 is then XORed 462 with the ECC2 decoding output 460 and fed into the ECC 1 decoding (reverse algorithm of the ECC1 encoding algorithm 427) algorithm 464. Successful ECC1 decoding 465 indicates that the client's location is verified together with the shuffling key 407. This corrected ECC1 output is then XORed 467 with the enrolled Keyphone 469. If the client 110 has used the correct Keyphone 440, the scheme will then retrieve the binary format of the time 486 used at the client side 105, and converts it back to its decimal format 487. Finally, if the retrieved time passes the liveliness test 490, then this authentication request is authentic 198.

Otherwise, the received OTMFBR 455 will be considered as a replay attack and the authentication request is considered as not authentic 195.

For the embodiment of the third authentication scheme 400, fig. 5. shows a block diagram illustrating the location binarisation algorithm used, reference numeral 500. This algorithm starts by obtaining the Cell-ID 505 of the cellular network serving tower/basestation 190.

Then, the geographical location of this basestation is determined 510 from a dedicated database 515. Concurrently, the geographical location of the mobile-handset 140 is obtained 520 from the mobile-handset onboard GPS receiver 125. These two locations are then used to calculate 525 the Manhattan distances on the X-axis 530 and Y-axis 535 between the mobile-handset 140 and the basestation. These distances 530, 535 are then divided by a pre-defined distance resolution 545 and rounded 540 to determine the required number of X/Y-Distance binary bits 550, 565 to express the distance between the mobile-handset 140 and the serving tower 190. Simultaneously, an "X-axis" 575 and an "Y-axis" 580 default binary string containing the same number of "Os" and "ls" are generated 555, 560. The number of "is" in the binary strings is thereby determined by dividing a pre-defined maximum distance 595 by the pre-defined distance resolution 545. The functions inside the box 590 are performed only once upon the installation and configuration of this third scheme. The single bit values in the default binary string for the X-axis 575 and the Y-axis 580 are then adjusted to represent the actual distance between mobile-handset and basestation. "X-Distance number of binary bits" 550 are changed from "1" to "0" in the X-axis default binary string 575, if the geographical location of the mobile-handset 140 is closer to the equator than the geographical location of the basestation 190. Else, "X-Distance number of binary bits" 550 in the X-axis default binary string 575 are changed from "0" to "1". The same operation is applied simultaneously to the Y-axis default binary string 580 with respect to the "Y-Distance number of binary bits" 565. The resultant two binary strings are then concatenated 560 to build the final binarised location 475.

This invention schemes and their embodiments may be used in various applications requiring remote authentication using wired or wireless communication. Examples of such applications include authenticating financial transactions between a bank and their clients, between a client and a certification authority, between companies and their employees, between cellular operators and their subscribers, between internet/web-shops and their members and customers. These applications may be used on any mobile devices such as mobile-handsets, laptops at client side.

Claims

CLAIMSThis patent claims are: 1. A process of using multi-factor Client-data based on various sensors residing on a mobile-handset device such as mobile Smartphones or tablet PCs to authenticate "the Client" to a remote site such as a certification authority centre, a bank or any other server site for the purpose of approving, validating, authenticating, proofing and permitting financial or nonfinancial transactions and contracts involving that Client with any remote site or "the Authenticator".
2. The Client-data in claim 1 shall include any combination of Biometric data obtained from sensors on the mobile-handset such as camera to extract features of the Client's face and/or iris and/or other physical parts recognition, finger print sensor to identify any of the Clients finger print, handwriting pad to extract the Client's signature, voice recognition encoder to capture specific tones of the Clients voice when saying a specific sentences, keypad to capture specific combination of the Clients number combination for a secret PIN or from a radio-based cryptographic token, infra-red sensor to detect the Clients palm-veins or a specific code sequence from a special cryptographic-token device, location of the Client' s mobile-handset is achieved in real-time at the start of the authentication process using the GPS, Wi-Fi or other receivers onboard the mobile-handset or obtained via the cellular network localisation methods or calculated from a combination of these and other inertial and/or other sensors such as gyroscopes and accelerators.
3. A combination of the Client-data in claim 2 shall be combined in processes to form a one-time-multi-factor-Biometric-Representation OTMFBR message that will be sent to the Authenticator site via any form of secure data link by means of wireless communication via the cellular network used by the Client's mobile-handset.
4. The Authenticator in claim 3 and in claim I refers to the site server where the Client has been previously subjected to a registration or an enrolment process and where the Client' s-data in claim 2 obtained from various biometric and authentication data has been extracted and his/her own features and number combinations have been agreed between the Client and this Authenticator.
5. The enrolment data registered by the Authenticator in claim 4 include the Client's biometric template or cancellable biometric template, User Based Random Projection key, geographical areas of Client's operation and time of transaction, shuffling key, PIN, Radio based token type and cryptographic number and/or phone key pad tone number combination.
6. The Authenticator in claim 4 shall process the received OTMFBR from its Client using similar tools, programs and software algorithms used to generate the OTMFBR at the client's side, and so enables the recovery of the necessary data that was sent by the Client to perform the authentication in a specific order that shall be adopted by the Authenticator.
7. The authentication process of claim 1 includes the authentication of the Client's claimed mobile-handset physical location as well as the actual time of the transaction as used by the Client, and so ensuring that the Client's claimed location is genuine and also to ensure that the Client has not violated what was pre agreed with the Authenticator during registration/enrolment on where and when such transactions can take place.
8. The authentication process for claim 7 is based on comparing the location and time of the Client's mobile-handset using two independent sources of time and geographic localisation associated with the Client's mobile-handset that are obtained in the first instance from the onboard mobile-handset GPS or Wi-Fi receivers for example, and also location and time that is independently obtained by the Authenticator, for example, from the cellular wireless operator's basestations based localisation techniques such as eTDOA via the networks SMLC in GSM for example.
9. A User Based Random Projection (UBRP) technique that uses random orthonormal matrices generated from the Client's PIN, password or token is used in the authentication process in claim 1 to project the Client's biometric feature vectors detailed in claim 2, into other secure spaces, as long as, the distances of these vectors before and after the transformation are preserved so to secure transformation for biometric templates to meet the revocability property of biometric-based authentication systems.
10. A Password-Based Shuffling (PBS) algorithm shall be used in the process of claim 1 to shuffle the Client's data by, as an example of a shuffling key, first dividing the Client's data in claim 2 into k blocks, where k is the size of the shuffling key and where If key(i) = 1 for i=l,2,. .k, then the corresponding data block is moved to the beginning of the shuffled data; otherwise it is moved to the end.
11. A scheme to generate the OTMFBR message in claim 3 is constructed by capturing real time fresh biometric sample of the Client using his/her mobile-handset sensors, and extracting a biometric feature vector while concurrently obtaining a Time-and-Location (T&L) information from the onboard mobile-handset GPS or Wi-Fi receiver where a copy of this fresh T&L is then attached to the OTMFBR while another copy is crypto-hashed to produce a shuffling key for the algorithm in claim 10 to shuffle this freshly extracted biometric feature vector which is then transformed into a secure domain by employing random orthonormal projection in claim 9 to send the OTMFBR to the Authenticator side.
12. A scheme that receives the OTMFBR in claim 11 at the Authenticator side where the Authenticator extracts the time, location and OTMFBR from the message and ensures, as a first step, that the Client's mobile-handset claimed location & current time are within the pre-agreed area & time of operation after which the Authenticator shall request the current position of the Client's mobile-phone directly from the Client's cellular network operator and verifies that the mobile-handset is actually at the claimed location by comparing the transmitted GPS/Wi-Fi position from the phone with the position obtained from the network operator so that if the location difference is within a certain threshold pre-agreed by the two parties then the authentication process will continue otherwise the authentication will fail.
13. The Authenticator shall continue claim 12 by using its stored information of the Client's enrolled biometric template, the password/PIN hash value as well as the time and location information to generate a local OTMFBR which is then compared with the received OTMFBR from the Client to verify that the Client is genuine.
14. A biometric binarisation process shall be used in claim 3 to convert biometric feature vectors into binary forms using for example 3x3 mask where the middle value is zero if it is greater that the mean of all other mask values otherwise it is a one.
15. A Biometric Error Correcting Code (BECC) algorithm is used in claim 3 to tolerate the binary differences between the binary representation of the Client's captured biometric sample on the mobile-handset calculated in claim 14 and the enrolled binary biometric template stored by the Authenticator.
16. A process to generate the OTMFBR message in claim 3 is constructed from XORing two data messages the first of which is generated from live Time and Location (T&L) obtained by the Client's mobile-handset GPS/Wi-Fi receiver, then converted to binary representation which is then shuffled by a shuffling algorithm in claim 10 and fed into an Biometric Error Correcting Code (BECC) encoding process in claim 15, while the second message is a fresh Cancellable Biometric Binary Representation concurrently generated from a real time freshly captured Client biometrics where the features are extracted and randomly projected as in claim 9 followed by biometric binarisation in claim 14.
17. A process, at the Authenticator side, that receives the OTMFBR message data generated in claim 16 and XOR it with the stored cancellable binary biometric template of this Client and the resulted data is then fed into a local BECC decoding process similar to the one used in claim 16 to authenticate that the received biometrics matches that of the Client's enrolled biometrics else the authentication attempt will fail, otherwise the authentication process continues by applying the inverse shuffling process in claim 10 on the output of BECC data to re-produce the binary representation of the OPS/Wi-Fi Time and Location generated in claim 16 that is then converted back to its original decimal representation so that time is used to check the liveliness of OTMFBR and the location is verified by requesting the Client's location independently from the Cellular network operator in claim 8 to authenticate it is s within a certain pre-agreed threshold before approving this authentication attempt otherwise the authentication will fail.
18. A Location Error Correcting Code (LECC) algorithm is used in the process in claim 3 to tolerate the difference between the two binary representations of the Client's location obtained from any two independent localisations sources in claim 8.
19. A Location Binarisation algorithm is used to generate a binary representation of the longitude and latitude value of the Client's location in claim 8 irrespective of the source supplying the location coordinates to standardise the format into a compatible representation, based on the cellular serving cell location as a reference point and which is only known to the mobile-handset and its network operator, so to allow the Location Error Correcting Code in claim 18 to compare the two independently supplied location coordinates.
20. A process that converts the GPS/Wi-Fi time to a binary format then XOR it with a key stored on the Client's mobile-handset where the result is then fed to an LECC encoding process in claim 18 and then XORed with the freshly generated binary representation of the acquired location in claim 19 after the binary location representation was shuffled as in claim 10.
21. A scheme to generate the OTMFBR message in claim 3 is constructed from XORing two data messages the first of which is a fresh Cancellable Biometric Binary Representation generated in claim 16 while the second message concurrently generated by the Error Correction Code encoding process in claim 15 is applied on the output of the scheme in claim 20 to send the OTMFBR to the Authenticator side.
22. A scheme, at the Authenticator side, retrieves the stored cancellable binary biometric template and XOR it with the received OTMFBR in claim 21 where the output is then fed into a local Biometric Error Correction Code (BEEC) decoding process in claim so to authenticate that the freshly captured biometric sample matches the enrolled one before continuing with the authentication process by XORing with the requested Client's location from the Cellular network operator as in claim 8 after subjecting it to the binarisation in claim 19 and shuffling in claim 10 before feeding into a LECC decoding process in claim 18 where an unsuccessful LECC decoding leads failing the authentication process otherwise the claimed Client's location is authenticated as genuine and the authentication process continues by XORing the data with the enrolled key stored on the Client's mobile-handset to retrieve the binary timestamp that get converted to check the liveliness of the received OTMFBR before approving this authentication attempt.