WO2006035421A2

WO2006035421A2 - Enhanced electronic financial system

Info

Publication number: WO2006035421A2
Application number: PCT/IL2005/000750
Authority: WO
Inventors: Michael Segev; Zvi Tal
Original assignee: FIBIOTECH-ADVANCED TECHNOLOGIES Ltd
Current assignee: FIBIOTECH-ADVANCED TECHNOLOGIES Ltd
Priority date: 2004-09-28
Filing date: 2005-07-14
Publication date: 2006-04-06
Anticipated expiration: 2007-03-28
Also published as: WO2006035421A3

Abstract

In an electronic financial system (EFS), a method for conducting a secured transaction in respect of a user. The method including receiving reference security measures that include encrypted PIN data, user identification data and biometric data of the user. The method further includes receiving a request for the transaction. The method further includes determining according to a security criterion and sensitivity level, the security measures that apply and comparing them to corresponding reference security measures for authenticating or not the transaction.

Description

ENHANCED ELECTRONIC FINANCIAL SYSTEM

The present invention is based on a Provisional Patent Application No. 60/613,223 filed September 28, 2004 whose contents is incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

This invention relates to security of enhanced electronic financial systems (EFS).

BACKGROUND OF THE INVENTION In spite of increasing investments in the EFS (Electronic Financial

Services) markets, fraud is still a major inhibitor to the growth and development of the industry.

There is thus a need in the art to provide for a new electronic finance system.

SUMMARY OF THE INVENTION

There follows a glossary of terms that pertains to certain embodiments of the invention. Some of the terms are conventional and others have been coined. The invention is not bound by these terms.

AIA - Authorization, Identification & Authentication BID - Biometric Identification Device

BRD - Biometric Registration Device

CBRA File - Central Biometric Registration and Authentication File

CRAM - Central Registration / Authentication Module

DIS Module - Data and Information Security Module EFS - Electronic Financial Services

EFSM - EFS Machine EFSP - Electronic Financial Services Provider

SEM - Security Evaluation Module

SSL - Security Sensitivity Level

TIA - Triple Independent Action

In accordance with the invention, there is provided a method and system for enhancing the security of electronic financial services (EFS).

In accordance with certain embodiments, a user (customer) can access financial services provided by an EFS provider through automated terminals - electronic financial service machines (EFSM), such as ATMs and POS terminals, which combine conventional EFS security with biometrics, together offering enhanced security while maintaining the convenience the users are accustomed to and without the need to change the existing cards or infrastructure, or to require the customer to carry any additional card or device, allowing the integration of the enhanced security provided into existing EFS systems, while causing substantially no disruption to existing systems and procedures.

In accordance with certain embodiments, the user registers with the EFS provider (EFSP) at a controlled location, such as a branch office, using a biometric registration device (BRD). The registration process ties together biometric sample readings of the user with his identification as known to the

EFSP, allowing the user to access with enhanced security any EFS offered by the

EFSP, current or future. The BRD requires that the user identifies himself by means such as an existing card - for instance, either the conventional magnetic card or an integrated circuit card (ICC, commonly known as chip card or smart card) - accepted by the EFSP, optionally together with the user's PIN, in addition to being certified in loco by trusted personnel. By these embodiments, the registration unit (located in this example the branch office) receives reference security measures that include at least the PIN data (in an encrypted form-), user identification data (such as data extracted from a user's credit card) and biometric data. Note that the invention is not bound by any specific means for receiving the reference security measures.

Bearing this in mind, the BRD then sends the registration data, secured by its data and information security (DIS) module (DIS/B), to the EFSP, which, in turn, after verifying the PIN (if this option was selected by the EFSP), sends the registration data to the central registration and authentication module (CRAM) for recording on the central biometric registration and authentication file (CBRA) after decryption and authentication by the CRAM DIS (DIS/C), and if the registration succeeds, sends a confirmation message back to the BRD to be presented to the user.

In accordance with certain embodiments of the invention, the design of the CRAM allows a single registration to serve multiple accounts or services for the same person and it also allows multiple persons to be authorized for a single account or service. After successfully registering with the system, the user may use any

EFSM supported by his EFSP. Thus, in accordance with certain embodiments, after identifying himself with his card, the EFSM may offer or require security measures (and sensitivity thereof) to apply according to security criterion, such as transaction type selected by the user or other criterion determined by the EFSP. The security measures can be, for instance (i) PIN and identification data, or (ii) PIN, identification data and biometric data which are reflected in the security sensitivity level (SSL). In accordance with certain embodiments, the SSL is determined by the central SEM, but the EFSP may distribute elements of the relevant policy to the DIS/E thus avoiding an additional interchange. The SSL may be, for example, such that enhanced security is not required (obviating the need to utilize biometric data), or in accordance with another embodiment, it may be such that a certain degree of certainty in the biometric identification is required. By one example, this determination results in a requirement for PIN entry or biometric verification or both, and if biometric verification is required, what degree of certainty to apply. The security criterion may be, for example, the type of transaction and the sensitivity level prescribes what security measures to apply and/or to what extent. For instance, cash withdrawal (one transaction type) requires a higher level of sensitivity (and therefore more measures and/or applying measures in a higher degree of certainty) compared to another transaction type that inquires on the balance of account of the user.

In the case that biometric data is required, then in accordance with certain embodiments, the CRAM sends to the EFSM the biometric data and parameters secured by its DIS module (DIS/C). The data is decrypted and authenticated by the EFSM DIS (DIS/E) and sent by the DIS/E to the biometric identification access device (BID) which is integrated into the EFSM, where it is used to perform the biometric identification. The results are encrypted and authenticated by the DIS/E and attached to the financial request message prepared by the EFSM.

In operation, in accordance with certain embodiments, the EFSP receives the financial request from the EFSM, performs the conventional business-as- usual (BAU) checks and verifications, such as account balance, exception files and transaction limits. If the BAU checks are successful, the EFSP sends the biometric data received from the EFSM to the CRAM. The CRAM, after decryption and authentication by the DIS/C, and obtaining the biometric data from the CBRA and the assigned SSL, verifies that the biometric data is close enough to the registration samples to satisfy the required degree of certainty according to the SSL. The CRAM then registers the transaction and returns an appropriate reply message to the EFSP: approved, declined, or request retry. Additionally, if the transaction is accepted, the biometric registration data in the CBRA may be updated. As is generally known per se, biometric data of an individual may vary over time and therefore real time biometric data of the individual are updated in the CRBA during actual use of the system. The CRAM includes suitable controls to detect and deal with repeated declined trials and to interface with any fraud control system that the EFSP may require. In accordance with certain embodiments, the EFSMs are installed at various locations and are connected to the EFSP through a communications network. The communication network may or may not be secured, however the CRAM and CBRA are assumed to be located in a secure and controlled location. Data sent and received between the EFSM and the CRAM is encrypted and authenticated using cryptographic facilities. The DIS/E module is a secure cryptographic module integrated within the EFSM.

Likewise, the BRDs are installed at various locations and are connected to the EFSP through a communications network. All the data sent and received between the BRD and the CRAM is encrypted and authenticated using known per se cryptographic facilities.. The DIS/B module is a secure cryptographic module integrated within the BID that provides the cryptographic services to the BRD.

The known per se cryptographic facilities that may be utilized in the specified DIS/B and DIS/E modules are, for instance: DES, Triple DES, AES SHA-I₅ RSA, etc.

In accordance with certain embodiments, the CRAM, in addition to providing the cryptographic services that are needed to match those of the EFSM and BRD, encrypts the sensitive data stored in the CBRA. In accordance with certain embodiments, the required DIS/C uses a commercially available hardware security module (HSM) to implement the selected cryptographic facilities.

Having briefly described an architecture and manner of operation of a system in accordance with various non-limiting embodiments of the invention, the invention provides, in accordance with the invention an electronic financial system (EFS), a method for conducting a secured transaction in respect of a user, comprising: (a) receiving reference security measures that include encrypted PIN data, user identification data and biometric data of the user; (b) receiving a request for the transaction; (c) determining according to a security criterion and sensitivity level, the security measures that apply and comparing them to corresponding reference security measures for authenticating or not the transaction.

The present invention further provides an electronic financial system (EFS) for conducting a secured transaction in respect of a user, comprising a registration unit configured to receive security measures that include encrypted PIN data, user identification data, and biometric data; an end user unit configure to receive a request for the transaction, the unit being associated with security measures system that includes PIN module, user identification module and biometric module; a processor configured to communicate with said end user unit and security measures system for determining, according to a security criterion and sensitivity level, the security measures that apply; said processor is configured to communicate with said end user unit, for receiving said selected measures, and comparing them to corresponding reference security measures, according to said sensitivity, for authenticating or not said transaction.

Further provided by the present invention An electronic financial system (EFS) for conducting a secured transaction in respect of a user, comprising: a registration unit for receiving security measures that include encrypted PIN data, user identification data, and biometric data, stored Central Biometric Registration and Authentication (CBRA) File; an end user unit configured to receive a request for the transaction, the unit being associated with security measures system that includes PIN module, user identification module and biometric module; a processor including a Central Registration/ Authentication Module (CRAM) coupled to said end user unit and security measures system and configured to determine, according to a security criterion and sensitivity level, the security measures that apply; said processor is configured to communicate with said end user unit, for receiving said selected measures, and comparing them to corresponding reference security measures, using to said sensitivity, for authenticating or not said transaction, the communication between the end user unit and the processor is secured by Data and Information Security (DIS) Module.

Yet further provided by the present invention is an electronic financial system (EFS) for conducting a secured transaction in respect of a user, comprising a processor configured to receive, through a communication link, from a registration unit security measures that include encrypted PIN data, user identification data, and biometric data; the processor is configured to receive, through a communication link, from an end user unit a request for the transaction, the processor is configured to determine according to a security criterion and sensitivity level, the security measures that apply; said processor is configured to communicate with said end user unit, for receiving said selected measures, and comparing them to corresponding reference security measures, using to said sensitivity, for authenticating or not said transaction.

The present invention further provides in an electronic financial system (EFS) for conducting a secured transaction in respect of a user, comprising an end user unit configured to receive a request for the transaction, the unit being associated with security measures system that includes PIN module, user identification module and biometric module; the end user unit is configured to communicate to a processor through a communication link, for determining selected security measures, and communicating said selected measured to the processor through said link, for authenticating or not said transaction.

Yet further provided by the present invention is a computer program product that includes a storage for storing a computer code for conducting method steps implementing a secured transaction in respect of a user in an electronic financial system (EFS), the method steps comprising: (a) receiving reference security measures that include encrypted PIN data, user identification data and biometric data of the user; (b) receiving a request for the transaction; (c) determining according to a security criterion and sensitivity level, the security measures that apply and comparing them to corresponding reference security measures for authenticating or not the transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to understand the invention and to see how it may be carried out in practice, a preferred embodiment will now be described, by way of non- limiting example only, with reference to the accompanying drawings, in which:

Figs. IA-B illustrate overview of a system architecture in accordance with an embodiment of the invention;

Fig. 2 is a block diagram of an Electronic Financial Services Machine (EFSM), used during normal mode of operation, in accordance with an embodiment of the invention;

Fig. 3 is a block diagram of Biometric Registration Device (BRD), used during registration mode of operation, in accordance with an embodiment of the invention;

Fig. 4 illustrates a registration request field structure, in accordance with an embodiment of the invention;

Fig. 5 illustrates a registration response field structure, in accordance with an embodiment of the invention;

Fig. 6 illustrates a transaction request field structure, in accordance with an embodiment of the invention;

Fig. 7 illustrates a transaction response field structure, in accordance with an embodiment of the invention; Fig. 8 illustrates a flow diagram of registration sequence of operation in the system of Fig. I₉ in accordance with an embodiment of the invention;

Fig. 9 illustrates a flow diagram of usage sequence of operation in the system of Fig. I₉ in accordance with an embodiment of the invention; Figs. lOA-C illustrate system display notifications, in accordance with an embodiment of the invention;

Fig. 11 illustrates a block diagram of a Data Information Security (DIS) module, in accordance with an embodiment of the invention; and Fig. 12 illustrating a block diagram of SEM analysis module, using

Security Sensitive Level (SSL), in accordance with an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the present invention. Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification, discussions utilizing terms such as , "processing", "computing", "calculating", "determining", or the like, refer to the action and/or processes of a computer or computing system, or processor or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities within the computing system's registers and/or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices.

Embodiments of the present invention may use terms such as, processor, computer, apparatus, system, sub-system, module, unit, device (in single or plural form) for performing the operations herein. Any of the above may be specially constructed for the desired purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read¬ only memories (ROMs), random access memories (RAMs), electrically programmable read-only memories (EPROMs), electrically erasable and programmable read only memories (EEPROMs), magnetic or optical cards, or any other type of media suitable for storing electronic instructions, and capable of being coupled to a computer system bus.

The processes/devices (or counterpart terms specified above) and displays presented herein, are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the desired method. The desired structure for a variety of these systems will appear from the description below. In addition, embodiments of the present invention are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the inventions as described herein.

Turning now to Fig. IA, there is shown an overview of a system architecture in accordance with an embodiment of the invention. As shown, the system includes a central control sub-system (100), an

Electronic Financial Services Machine (EFSM) unit (6) (being for example commercially available ATM) and a Biometric Registration Device (BRD) (7) communicating through an Electronic Financial Services Provider network (5), constituting an example of a communication link. Turning at first to the control unit (100), it includes a Central Biometric

Registration and Authentication (CBRA) File (1) being the central repository of the registration and authentication data, containing the biometric reference measurements and history, and the account holder identification, stored in a protected manner. The Central Registration / Authentication Module (CRAM) (2) is a module that controls the registration, data protection and authentication processes. In addition, CRAM further stores/extracts data from the CRBA. The Electronic Financial Services Provider (EFSP) (3) coupled to the CRAM has a computer system that handles the transactions and whenever required, contact the CRAM when biometric authentication or registration are required. Note that known per se modules perform business as usual checks such as authenticate the user identification data (e.g. information that pertains to the user and stored on the user's card), checking and authentication of the PIN and possibly other tests.

Reverting now to Fig. 1, the Security Evaluation Module (SEM (4)) provides an interface (possibly configurable) between the transaction systems of the EFSP and the CRAM that implements the security policy of the EFSP, assesses, for example, the transactions and determines the required Security Sensitivity Level (SSL). As will be explained in greater detail below, the SSL determines which security measures to apply (e.g. whether to apply biometric test or not) and to what extent according to security criterion, such as the type of the transaction, its monetary value, etc.

The Data and Information Security Module (DIS/C) (8) provides, amongst the others, cryptographic functions to the CRAM, using, in accordance with certain embodiments, cryptographic algorithm(s) approved and accepted by financial institutions, such as DES, Triple DES, AES, RSA, and SHA-I . The cryptographic algorithm(s) are used with specific message formats that include variable data used uniquely during each transaction in order to prevent replay, all as known per se. The cryptographic keys required for these facilities are managed according to known per se key management processes, without the use of plain text keys, and allowing appropriate control and audit procedures. The invention is, of course, not bound by these implementations.

In accordance with certain embodiments, the DIS/C includes commercially available hardware security module (HSM), such as Thales RG- 8000, that performs the required cryptographic functions for the CRAM. The EFSP is connected through communication link (such as existing network or networks (5)) to multiple EFSMs (6) and BRDs (7). In accordance with certain embodiments, the network can be any wired and/or wireless communication network, for instance the existing EFSP network. Turning now to the Electronic Financial Services Machine (EFSM) (6), it contains, in addition to other elements, the DIS protocol (101), which is an interface between the EFSM and the EFSP and is based on the existing EFSM protocols with some extensions, and in particular, in certain embodiments, the extensions include the biometric related modules and the associated security modules. As will be explained in greater detail below, the DIS/E module (102) which implements the DIS protocol handles the cryptography and the Biometric Identification Device BID (103) module that actually performs the biometrics, all as explained in greater detail below. Note that the invention is not bound by any specific biometric device, and accordingly, any known per se biometric technique using fingerprints data, retinal data and/or other data identifying the user, can be used.

Turning now to the Biometric Registration Device BID (7), it is applicable during registration phase (as will be explained in greater detail below) in contrast to the EFSM module which is applicable to actual use of the system. The BID implements the DIS protocol 101 ' (similar to 101), however, identified as DIS/B which is an interface between the BRD and the EFSP. The DIS/B (102') module which implements the DIS protocol, interfaces with BRD devices and handles the cryptography, and the BID module that actually performs the biometrics. The EFSM module and the BRD may reside in distinct physical devices, or in certain embodiments in the same devices. For instance, in accordance with certain embodiments, the EFSM, say ATM, may perform also the registration phase (the functionality of the BRD), serving thus also as registration unit, insofar as biometric data are concerned. Note, incidentally, that the C in the DIS/C module indicates that the DIS module is operable at the central side (both during registration and normal use phases), whereas the DIS/B, fitted in the BRD module is operable during the registration phase, and the DIS/E module fitted in the EFSM [client] side is operable during normal use phase. Note also the letters appended to the DIS serve to indicate the following: (i) DIS /B, where B being indicative of BRD used in the registration phase; (ii) DIS/C, where C being indicative of CRAM (residing at the central side); and (iii) DIS/E where E being indicative of EFSM (residing at the user side). Those versed in the art will readily appreciate that the specified markings are for convenience only and accordingly, the structure and operation of the DIS modules are not bound by this specific example.

Those versed in the art will readily appreciate that the invention is not bound by the specific realization of system architecture as depicted in Fig. IA and accordingly, other designs of the system and/or of one or more of the distinct sub-systems (control 100, EFSM 6 and BRD 7) are applicable, all as required and appropriate, depending upon the particular application.

Turning now to Fig. IB, it illustrates a more generalized overview of the system architecture, in accordance with certain embodiment of the invention. As shown, there is provided a registration office (110) containing a BRD (7 above), that forms part of a registration unit and communicates through the network (111) to the control unit which accommodates the CRAM (112). The latter controls the overall registration process and storage of the registered reference data (being an example of the reference security measures) of the user in CBRA file (113). The reference data includes reference biometric data of the user. The communication is performed using the DIS modules depicted schematically in the Fig. IB as "lockers". The DIS modules whose operation will be described in more detail below, apply, amongst the other, cryptographic functionalities.

Also shown in Fig. IB, an EFSM (114) (say, conventional ATM or POS) is used in the process of request/authenticate transactions. The user approaches the EFSM (114), selects the requested transaction (through known per se interface), and according to security criterion, (as will be explained in greater detail below), a sensitivity level is determined in respect of security measures. The latter being, in accordance with certain embodiments, PIN data (115) (in an encrypted form), card data (116) (the latter being one example of user identification data), and biometric data (117)). The so provided data are fed to the control unit through the network, (shown schematically as 118). The data is subject to encryption/decryption through add-on DIS modules (designated 118' and 118", respectively). The so fed data is compared with the stored reference security measures (by the CRAM) in order to determine whether or not to authenticate the transaction.

The SSL may determine what is the degree of certainty that is required in the result (of the comparison) in order to authenticate the transaction.

There follows a description for explaining the use of biometric data in a sequence of operation (for authenticating a transaction) in accordance with certain embodiments of the invention. The description below assumes, for simplicity, that biometric data check is required. As will be noted later, this is not always necessarily the case.

Thus, as specified above, the request/authenticate transaction processing may involve processing of biometric data. In accordance with certain embodiments, the reference biometric data of the user (obtained during the registration phase) is stored in the center (e.g. in the CBRA file). Generally speaking, known biometric data authentication algorithms compare reference biometric data to tested biometric data and provide an output indication ( number that falls in a certain range ) indicative of the matching degree between the reference and tested data, such that the larger the number, the higher the matching degree between the reference and tested data. Note that the invention is not bound by the use of any specific biometric algorithm.

By one embodiment, the algorithm is incorporated at the end unit, e.g. in DIS 118') and accordingly, when it is required to check biometric data (e.g. according to the transaction requested by the user), the (reference) stored biometric data is transmitted along with the sensitivity level data (in an encrypted form) from the center to the end unit. Note that the sensitivity level is extracted from the CRAM in the center and is fed to the DIS at the user end unit.

The DIS (118') at the user end, decrypts the received reference data which is then fed to the BID unit 117. The tested biometric data of the user is acquired at the BID which compares the tested vs. the reference biometric data and provides as an output the matching degree between the two. According to the sensitivity level, the DIS 118' determines whether the matching level (as obtained from the BID) is sufficient to authenticate the transaction. For instance, a "obtain balance of account" transaction may be associated with a lower sensitivity level compared to a "buy shares" transaction. Depending on whether the matching level meets (or not) the sensitivity level requirement, the DIS either approves or declines the requested transaction. Note that the DIS 118' may use the updated biometric data of the user which was obtained by the BID (and which normally varies over time) and transmits them in an encrypted form to the center in order to update the stored reference biometric data of this particular user.

In accordance with certain other embodiments, the DIS may apply other conditions. For instance, in case of failure (i.e. the matching level does not meet the level prescribed by the sensitivity level), the user may be prompted to feed tested biometric data again, up to, say X attempts.

Note that in certain other embodiments, the sensitivity level data may reside at the end unit (say the DIS) instead of the center.

In accordance with certain other embodiments, the biometric algorithm resides in the center (say the CRAM 112). Thus, the tested data is transmitted (in an encrypted form) by the DIS module (fitted at the user end) and after having been decrypted (at the center), a comparison is effected at the center between the tested and reference data (as extracted from the CBRA file 112) and depending upon the result and the required sensitivity level, the center authorizes or not the transaction. As before, the sensitivity level may vary, e.g. according to the type of the transaction. In the case that the transaction is authorized, the appropriate data is transmitted in an encrypted form to the DIS at the user end. For example, if the transaction inquires on a balance of account, then the balance of account data is transmitted (in an encrypted form) over the network 118 to the DIS 118', the latter decrypts the data and forwards it to the EFSM for displaying the sought data to the user.

The invention is not bound by the specified embodiments of using biometric data checks.

Bearing this in mind and reverting to Fig. IB, the EFSP network (119) aims to represent the conventional transportation using known per se protocols between the EFSM (say ATM) and the center. Note that the reference to distinct networks (111,118 and 119) is for illustrative purposes only, and they can actually form one common network or different networks, whichever the case may be. The invention is not bound by the use of any specific network and any known per se communication link or links, is (are) applicable, depending upon the particular application.

Note that in accordance with certain embodiments, the electronic financial system of the invention provides an add-on solution to existing EFSMs (say ATMs,) which will be enhanced by disjoint or integral biometric unit. The DIS modules may be coupled to existing communication protocols adding the encryption/decryption and other functionalities. The control unit may perform the testing of the user data in order to authenticate or not the transaction in a conventional manner in respect of certain security measures, say the encrypted PIN and/or the card. These operations of the control unit are generally known per se and therefore are not further expounded upon herein.

Note that the invention is not bound by the specified architecture. Thus, by way of non limiting example, in the control unit, different modules/units can be allocated to perform the registration/authentication tasks of the CRAM. By still another non-limiting example, the registration/EFSM functionalities can be performed in a single device, etc. Turning now to Fig. 2, there is shown a block diagram of an Electronic Financial Services Machine (EFSM), in accordance with the embodiment of Fig. 1.

This Figure presents the EFSM in further detail. The EFSM is an existing machine, which is enhanced by the addition of the DIS/E (11) and a BID (10). The DIS/E handles the downstream communications (12) (i.e. communication received from the EFSP through the network (5)), using a slight modification of the existing protocol, e.g. attaching the cryptographically protected biometric and other required data (as will be described with greater detail with reference to Figs. 4 and 5, below). The DIS/E accepts downstream communication messages from the EFSP through the EFSP network, and after stripping off the additional data (such as the cryptographic protected biometric data), passes the message, which is now identical to the unmodified original protocol, to the existing EFSM (9) communications port. As specified above, the EFSM may be for instance an enhanced ATM.

Likewise, for any (downstream) message from the EFSM (9) to the EFSP (through port 12), DIS/E accepts the message from the EFSM and attaches, if necessary, required data (e.g. attaches biometric data if available). The existing input modules of the EFSM devices (9), such as card reader, keyboard, display etc. are thus not affected by the security enhancement.

The DIS/E further interacts with the BID module. It decrypts and authenticates the biometric data received (downstream) from the EFSP and controls the BID including reading the biometric data. Insofar as the upstream data is concerned, the DIS/E accepts the biometric results from the BID (namely the user's biometric data), encrypts them and adds authentication data, such as Message Authentication Data (MAC). The DIS/E further adds the results to the transaction message from the EFSM, and sends the enhanced message to the EFSP though the EFSP network, for further processing by the control sub-system (10 in Fig. 1). In this connection, it is recalled that various alternatives of employing biometric algorithms are applicable, as explained in a non-limiting manner with reference to Fig. IB above.

Those versed in the art, will readily appreciate that the invention is not bound by the specific realization of EFSM architecture as depicted in Fig. 2 and accordingly, other designs of the system and/or of one or more of the distinct modules therein are applicable, all as required and appropriate, depending upon the particular application. As specified above, The BID module can be any commercially available device configured to receive and process biometric data of the user. Turning now to Fig. 3, it illustrates a block diagram of Biometric

Registration Device (BRD), used during registration mode of operation, in accordance with an embodiment of the invention.

This figure presents the BRD in further detail. The BRD is a machine containing a DIS/B module (15), a BID (13), a PIN entry device (PED) (16), and a card reader (CR) (14) that may be, for instance, a conventional magnetic strip reader, a smart card interface device or, and/or any other input means, for receiving user identification data. Note that the biometric data, PIN data (encrypted) and user identification data form part of security measures, in accordance with an embodiment of the invention. The DIS/B (B signifying that the DIS functions in the registration process) manages the downstream communications (17) (from the EFSP through the network), and it implements the DIS protocol and controls the registration process. The DIS/B receives the response message (Biometric data responses) from the EFSP through the EFSP network, decrypts and authenticates it, and displays the result. Note that the structure and operation of the DIS will be explained in greater detail below.

For upstream flow, the BRD accepts the customer's card through the card reader, and through the PED it securely accepts an encrypted PIN, it activates the BID in registration mode, obtains the biometric data, encrypts them and adds authentication data, and adds a certification by a trusted personnel, e.g. a personal ID code of the trusted person who handled the registration process vis- a-vis the user.

The BRD sends (downstream) the specified data to the EFSP though the EFSP network. The EFSP will then pass the message to the CRAM, for further processing as will be explained in greater detail, below.

Turning now to Figs. 4 and 5, there is shown respective registration request field structure (40), and registration response field structure (50), in accordance with an embodiment of the invention.

The registration request is transmitted from the DIS/B module (17 in Fig. 3). It includes Protocol version field (41) indicating the application protocol between the BRD unit and EFSP. It also includes Message type field (42) indicating the type of the message, say registration request. It further includes BRD ID (43), indicative of a unique identification of given BRD unit. In other words, each of the widely circulated BRDs has a unique (possibly hardwired) identification code which is inserted to field (43), enabling the remote control unit to identify the originating BRD. Fields (44) and (45) provide unique identification of the DIS/B and BID units (102' and 103' in Fig. 1), serving for the identification of these modules. Sequence number field (46) stands for a serial number of the message in the specified protocol. Customer ID (47) is the identification of the user (whose details are now registered), such as account number, passport number, etc.

The Card data field (48) includes data of the identification card (e.g. of magnetic card or smart card) of the user serving for accessing the EFSM, such as a VISA™ credit card used for accessing an ATM. The encrypted PIN block (49) including encrypted PIN code associated with the card of the user (e.g. the encrypted PIN code associated with the credit card). The encryption may be, for instance, CBC Triple DES or any other encryption accepted by the EFSP. For CBC, the DIS/B ID and the sequence number may be used to generate the Initialization Vector (IV). Turning now to additional encrypted data fields (400), they include the unpredictable number field (401) that accommodates an arbitrary selected number which vary in each transaction, thereby avoiding replay scenario, as generally known per se. Field (402) includes the customer ID (now in encrypted form) and the Certifier Data field (403) is used internally by the bank. The biometric data field (404) accommodates the (encrypted) biometric data, as extracted from the user using the BID unit (e.g. digitized fingerprint data). Lastly, the MAC code includes signature applied to the entire message 40.

The invention is, of course, not bound by the specific use of field structure in the manner specified and other variants are applicable, all as required and appropriate. For instance, whereas the structure (40) accommodates the entire data that relates to the request (including encrypted PIN, card identification data and biometric data), followed by a response (described with reference to Fig. 5, below), in accordance with another embodiment, the same data (or variants thereof) can be broken down to distinct blocks. Thus, for instance, encrypted PIN and card data (as the latter being an example of user identification data), can be submitted as a first stage and only if the specified user is accepted, the user is requested to provide additional data including the biometric data. In other words, the card data, encrypted PIN and biometric data (being an example of security measures), can be provided selectively, depending inter alia on security criterion and sensitivity level, all as explained in greater detail herein.

Turning now to Fig. 5, it illustrates a registration response field structure (50), in accordance with an embodiment of the invention. The protocol version, Message type, BRD ID, DIS/B ID, BID ID, Sequence number, Customer ID, Encrypted PIN block, Encrypted data, Unpredictable number, and MAC fields correspond to the counterpart fields in the registration request structure message (40).

The response code (51) is indicative of the result's status (such as accept, reject and in the latter case, the response code may indicate the reason for rejection: e.g. system fault, misidentification of the user, etc.) and the Biometric data (52) (e.g. the a priori stored reference biometric data), is the reply to the request (40). The invention is, of course, not bound by the specific use of field structure in the manner specified and other variants are applicable, all as required and appropriate. Having described the fields structure for the registration request and registration response phase, there follows a description of the field structures for the actual "use" transactions, serving for authenticating the secured transaction of interest (such as inquiry of balance of account, withdrawal of cash, conducting bank wiring from one account to the other, etc.). Thus, turning to Figs 6 and 7, they illustrate a transaction request field structure and transaction response field structures, respectively, in accordance with an embodiment of the invention.

Note that the use of the specified transactions is in the upstream communication (transaction request- 60) between the EFSM (6 of Fig. 1) and the EFSP (3 of Fig. 1) through link 12 (see Fig. 2), and in the downstream communication (transaction response- 70) between the EFSP the EFSM through link 12.

Turning at first to structure (60), it contains basically the same data as block 40 of Fig. 4 (registration request block), except for the Customer ID and Certifier ID fields (47 and 403, of Fig. 4), This data is already known from the registration phase. The data of structure 60 (including the encrypted PIN data,

- card data and biometric data, being an example of security measures) is transmitted through network 5, and is evaluated by the control unit 10 (in a manner described in greater detail below) in order to decide whether or not to approve the transaction. Note that in certain embodiments, it is not necessary to transmit all the data. For instance, in certain scenarios, the biometric data need not be sent. Or, in accordance with certain other embodiments, the biometric data is requested by the control unit after evaluating the encrypted PIN/ Card data. Note that the security criterion and sensitivity level may prescribe, inter alia, which data to transmit, whether to transmit it in one chunk, or in portions. The Transaction response field structure (70 of Fig. 7) includes counterpart fields, including indication whether the requested transaction has been approved. In the case that the biometric algorithm resides at the end unit, then, in accordance with certain embodiments, the biometric data field in structure 70 includes the reference biometric data of the user as extracted from the CRAM.

In other cases, where the biometric data resides at the end unit, then in accordance with certain embodiments, the need to transmit biometric related data of any kind to the end unit is obviated. Having described the field structures of registration request and response as well as transaction request and response, there follows a description (with reference to Fig. 8) of registration sequence of operation in the system of Fig. 1 (with reference occasionally also to Fig. 3).

The sequence of operation illustrates the tasks performed at the registration point end (the Credit card 14, the encrypted PIN entry code (16) and the BID (13) of Fig. 3), at the DIS/B module (15 in Fig. 3) and the Central Registration/ Authentication Module (CRAM - 2 in the control unit 10 of Fig. 1). Note that, whereas for convenience of explanation the registration sequence of operation refers to the system and modules of Fig. 1 (and occasionally also to Fig. 3), the registration sequence is by no means bound by this specific system architecture, and it may vary, depending upon the specific embodiment of the system.

Bearing this in mind, and as shown in Fig. 8, the user registers with the EFS provider (EFSP) at a controlled location, such as a branch office, using a biometric registration device (BRD) (7 in Fig. 1), serving as an exemplary part of registration unit. The registration process ties together biometric sample readings of the user with his identification as known to the EFSP, allowing the user to access with enhanced security selected EFS offered by the EFSP, current or future. The BRD requires that the user identifies himself by means such as existing card - for instance, either the conventional magnetic card or smart card) - accepted by the EFSP) (step 84), optionally together with the user's PIN (85, 86), in addition to being certified in loco by trusted personnel.

The registration data is sent to the DIS/B (82) which secures (including applying encryption) the data and information ((87) (as described for example with reference to Fig. 4) and transmits is to the EFSP (3 in Fig. 1). The EFSP, in turn, after verifying the encrypted PESf (if this option was selected by the EFSP), sends the registration data to the central registration and authentication module (CRAM (83)) for recording on the central biometric registration and authentication file (CBRA) after performing the DIS/C operation (including decryption and authentication (88)).

The CRAM authenticates the data (89) including checking (based on the card data and encrypted PIN data) whether the user is already registered (800). If the user is already registered, the process terminates (802). If the user is not registered (801), it is required to obtain biometric data and to this end, the biometric request data is initiated by the center (using conventional encryption/decryption DIS utility (803 and 804).

The user now provides the required biometric input (805) (say, digitized fingerprint data) that is transmitted to the EFSP for processing by the CRAM (after being subject to the DIS operations 806 and 807). If the registration succeeds (808, 809), including registering the biometric data in the CBRA), a confirmation message is sent back to the BRD (810) to be presented to the user (after having been subjected to the standard DIS/C and DIS/B modules (811 and 812) for performing amongst the other encryption /decryption and authentication of the transmitted message. The registration response message (see block 50 in Fig. 5) is transmitted from (809) to (810).

In accordance with certain embodiments of the invention, the design of the CRAM allows a single registration to serve multiple accounts and services for the same person and it also allows multiple persons to be authorized for a single account. Those versed in the art will readily appreciate that the invention is not bound by the specific sequence of operation described with reference to Fig. 8, and accordingly, other operational scenarios are applicable for registering a user.

Note also that, whereas the data structures in Fig. 4 (registration request) and in Fig. 5 (registration response) seemingly suggest that there is a single stage of submitting registration request (that includes the structure message 40) and a single response (that includes the structure response 50), the invention is not bound by such a two-stage operation. Certain embodiments which do not utilize a two-stage operation, have been exemplified with reference to Fig. 8, where few to and fro stages are used. In this embodiment, in each stage, the relevant data of the messages 40 and 50 is transmitted. Note also that the embodiment described with reference to Fig. 8 is not bound by the specific data structures of Figs. 4 and 5.

Having described a normal sequence of operations, there follows a description, with reference to Fig. 9, of a flow diagram (90) of regular usage sequence of operation (for authenticating the requested transaction) in the system of Fig. 1, in accordance with an embodiment of the invention. As shown, the participating parties are the user (91), the EFSM, (say ATM (92)), the DIS (93) (forming part of the EFSM, as shown in Figs. 1 and 2) and the CRAM 94. At the onset, the user feeds in the card (95) and in response to the EFSM request (96), he feeds in the PIN (97). The data is subject to the operation of the OlSfE (98) (including encryption and the data is transmitted over the communication network (5 in Fig. 1) to the EFSP). The data has generally the structure of the transaction request block shown in Fig. 6. As specified before with reference to the data structure of Figs. 4 and 5, it is not necessarily to submit in each phase the entire content of data structure 60.

The EFSM forwards the transaction request to the CRAM, which, after applying the DIS/C (to the received transaction request (99), including decryption), commences the operation of the CRAM for inquiring whether this is a registered customer (900). This inquiry is implemented using, for instance, the Card data and as extracted from the transaction request block compared to the data a priori stored in the CBRA (as a result of the registration phase) and verifying the encrypted PESf data.

In the case that this is not a registered user, the EFSM terminates operation and the user does not receive service (902).

If, on the other hand, the user is registered (903), a display menu is transmitted to the EFSM (through appropriate encryption/decryption using the DIS modules 904 and 905) and displayed at the EFSM (906).

Note incidentally, that there are known per se different implementation procedures for improving processing and/or communication complexity. Thus, in accordance with certain embodiments, various screen templates (including invariable data, such as field names), may be a priori stored at the end unit and accordingly, the need to transmit the entire screen data from the center to the end unit is obviated. Thus, for example, a code in field 51 (see Fig. 5) may identify the screen template that needs to be displayed, and, if necessary, additional (variable) data may also be transmitted (from the center to the end unit) and displayed.

The user now selects a service of interest (907) and the transaction request (after having been encrypted using the DIS/E) (908) is evaluated at the CRAM end (909), using, to this end, the Security Evaluation Module (SEM) module (see 4 in Fig. 1), whose operation will be described in greater detail below. Generally speaking, the SEM will determine the sensitivity level required for the security measures, according to security criterion, such as transaction type, etc. Thus, for instance, transactions that inquire on balance of account, may require lower sensitivity level compared to transactions that instruct to conduct a bank wiring from one account to another in respect of a significant amount of money. The latter example is by no means binding and the description below will refer in more detail to the SEM operation, including the sensitivity level and security criterion. Reverting now to Fig. 9, after having determined the sensitivity level (910) (based, e.g. on the transaction type etc.), it is determined whether biometric data is required (911). Note that, as a rule, the lower the sensitivity required (intuitively less sensitive transactions), the lesser the likelihood of requiring additional biometric data. And, if biometric data is required, lesser sensitivity may prescribe lower "match" degree between a priori stored biometric data and the so received biometric data (of the testes user) in order to authenticate the requested transaction.

Note that the need of biometric data requires the user to perform additional operation (such as placing the palm on the receiving interface of the Biometric Identification Device (BID) of the EFSM), which, not only prolongs the transaction time, but in some cases, may cause inconvenience (e.g. individuals, such as elderly persons who may encounter difficulties in properly placing the palm on the BID receiving interface). Accordingly, in accordance with certain embodiments, the sensitivity level and the security criterion is configurable, depending upon the specific requirements. For instance, it may be the case that, for certain customers with positive credit (as determined once the card/ encrypted PIN data is tested vis-ά-vis the stored data in respect of these individuals), the biometric data requirement may be triggered in respect of more sensitive transactions compared to other customers.

As specified above, in certain scenarios the SSL not only prescribes whether to apply biometric test, but also in what level of certainty. In accordance with certain embodiments, the more "sensitive" the transaction, the higher the level of certainty required for the biometric test. One possible implementation of the latter, is by using the resulting biometric score as a criterion. Thus, in accordance with certain commercially available biometric data testing techniques, when tested biometric data is compared to reference biometric data (in a biometric device), the latter outputs a numerical value indicative on the extent of similarity between the tested data and the reference data. Consequently, the higher the score (say closer to 1), the more similar are the reference and the tested data and the lower the score, the less similar are the tested and reference data.

Accordingly, in accordance with certain embodiments, the specified output score may serve for the SSL as follows: assuming that a security criterion is transaction type, then in the case that the SSL prescribes that, for certain transactions, biometric test is required as part of the security measures, it may further require different level of certainty. For instance, for a given transaction (say, bank wiring transaction between accounts belonging to different customers), a higher level of certainty is required (i.e., in the latter example, higher score in the resulting comparison is required), whereas for a different transaction that still requires to apply biometric test (say, bank wiring between different accounts belonging to the same customer), a lower level of certainty is required (i.e., in the latter example lower score in the resulting comparison is required). The invention is, of course, not bound by this specific example. Thus, in accordance with certain other embodiments, other biometric techniques can be used, and/or security criterion can be used in addition or instead of the transaction type. Note also that, depending upon the particular application, the security criterion can be further fine tuned. For instance, for a given transaction type limited by maximum first sum, a certain sensitivity is required, whereas for the same transaction type that is limited by higher sum, a higher sensitivity may be required, etc. The distinct criterion are not bound in any way and may be determined depending upon the particular application.

Reverting now to Fig. 9, in the case that no additional biometric data is required (912), the requested service is authenticated (say, the balance of account, or approval to withdraw cash, etc.) and is transmitted to the EFSM and displayed to the user (913). If, on the other hand, biometric data is required (914), a biometric data request is transmitted (using the decryption/encryption operations by the DIS (915)), and biometric data is fed by the user (916 to 918) and transmitted (in digital encrypted manner (919)) to the CRAM which checks the so received data against the biometric data a priori stored in the CBRA (920). Note, that the sensitivity level not only determines whether or not to require biometric data, but also what degree of matching is required between the received and stored biometric data. Moving on with Fig. 9, if the biometric data does not match at the required level of certainty (921), then the sought service is not authenticated (922) and consequently not provided, otherwise, in case that the sensitivity level is accomplished (923), (say the data matches in at least X%, where X is determined according to the security criterion and SSL), the requested operation is performed (924) (after having duly encrypted/decrypted and authenticated the transmitted data 925, 926).

Turning now to Figs. lOA-C, they illustrate system display notifications in normal use of transaction authentication sequence, in accordance with an embodiment of the invention. Thus, at the onset, the user is requested to enter the card (1000) (to the appropriate receiving means at the EFSM, say magnetic strip reader fitted in the ATM). Thereafter, the user is requested to enter the PIN number (1001), and immediately (or after checking whether it is required at the remote control unit, all as explained in detail above), the user is requested to place his hand on the BID reader interface (1002). The user is then requested to indicate the requested transaction (here a withdrawal of $150 cash) (1103). The system identified discrepancy between the input data and the particular of the user (1004) (after verifying the encrypted PIN data).

The user is now requested to re-feed PIN and biometric data once again (1004 and 1005), and since mismatch has been encountered again, the requested transaction is not authenticated (1006).

Note that the series of the notification messages illustrated in Fig. 10 is, by no means, binding. For instance, it may well be the case that the requirement to provide biometric input (which as specified may be burdensome for some customers), would be raised only after the transaction details are provided (here the $150 cash withdrawal), or would not be required at all (based on the security criterion and sensitivity level applied by the SEM module).

As has been described in respect of the certain embodiments of the invention, a DIS module is utilized. For a better understanding of the structure and operation of the DIS module, attention is drawn to Fig. 11 illustrating a generalized block diagram of a Data Information Security (DIS) module, in accordance with an embodiment of the invention.

As shown, in accordance with certain embodiments, there are three DIS modules as follows: DIS/B - the DIS registration module (1101), shown also in the BRD (7) of

Fig. 1.

DIS/E - the DIS module for the EFSM (1102), (used during normal mode of operation for authenticating transaction), shown also in the EFSM (6) of Fig. 1. DIS/C - the DIS module for the CRAM (1103), used for registration/authentication communications at the remote control unit (see DIS/C (10) in Fig. 1)

For a better understanding of the operation of the add-on DIS module, attention is drawn to Fig. 11, illustrating a block diagram of a DIS module, in accordance with an embodiment of the invention, and occasionally also to Figs. 6 and 7.

The description with reference to Fig. 11, applies to the DIS/E, however, in accordance with certain embodiments, it likewise applicable to the DIS/B. Note that in accordance with certain embodiments, the DIS/C performs know per se encryption/decryption functionalities.

Bearing this in mind, the DIS/E is installed within the EFSM and is connected on one side to the EFSM host connection and on the other side through the EFSP network to the EFSP. In effect, the DIS/E impersonates the EFSM towards the EFSP and impersonates the EFSP towards the EFSM. The DIS/E recognizes the existing EFSM communications protocol, for example Diebold 912, NCR Direct Connect (NDC), XFS etc., and analyses each message. Messages that the DIS/E is not concerned with, such as operational commands, status indications and acknowledgements, are passed from side to side unchanged in a transparent manner. Transaction messages, on the other hand, are analyzed. The transactions and the responses are identified according to the specific implementation of the EFSM protocol by the EFSP, and for those transactions that are customized to require biometric identification, the DIS/E intervenes and activates the BID according to the particular implementation requirements.

When the DIS/E receives from the EFSM a transaction that requires or may biometric identification, it builds a DIS protocol transaction request (Fig. 6), using data from the transaction request (for example, the card data and the EFSM Id), internally generated data (The DIS/E Id, the sequence number, the unpredictable number), data from the BID (the BID Id, Biometric data), and cryptographically calculated data (CBRA access code, MAC). The DIS protocol transaction request is then sent to the EFSP attached to the EFSM transaction request.

The DIS/E then receives from the EFSP a transaction response, which consists of the EFSM pre-existing transaction response and an attached DIS protocol transaction response (Fig 7). The DIS/E verifies the control data (EFSM Id, DIS/E Id, BID Id, sequence number) and rejects messages that do not agree with the last sent transaction request, authenticates the transaction response, and once authenticated decrypts the encrypted data. The decrypted data, which came from the CRAM, may indicate the biometric identification is not required for this transaction, in which case the DIS/E passes the EFSP conventional transaction response, with the DIS protocol removed, to the EFSM.

If the decrypted DIS protocol indicates that biometric identification is required, the DIS/E sends an appropriate message to the EFSM, according to the EFSM protocol, instructing the EFSM to display the relevant guidance messages, sends the necessary commands and data to the BID, and accepts the BID response.

The BID response may indicate that the biometric identification was successful, according to the criterion which was included in the DIS protocol transaction response encrypted data, or that it failed. The DIS/E sends an appropriate message to the EFSM, according to the EFSM protocol, either the original transaction response received from the EFSP or a modified transaction response indicating that the transaction cannot proceed.

The DIS/E contains several components that perform the various tasks required to implement the required functions (Fig. 11). The hardware 121 and the operating system 122 are commercially available components that serve as the platform for the DIS/E software. The DIS/E software consists of a control module 123, which sequences and manages all other software components according to the required functions, an upstream communications module 124 that handles the communications to and from the EFSP and implements the existing EFSP network protocol, a downstream communications module 125 that handles the communications to and from the EFSM and implements the existing EFSM protocol, a logic module 126 that analyses the messages received from the EFSM and the EFSP and processes them, and a cryptographic module 127 that provides cryptographic functions to the other DIS/E software modules, to encrypt, decrypt and authenticate the DIS protocol messages.

Note that in certain embodiments, the DIS module is an add-n module that does not interfere with the operations of the conventional modules and, obviously, it is not bound by the specific structure depicted in Fig. 11.

As may be recalled, in accordance with certain embodiments, which security measure to apply as well as the sensitivity level thereof, is determined according to security criterion, using in accordance with some embodiments a

Security Evaluation Module (SEM). For a better understanding of the foregoing, attention is now drawn to Fig. 12, illustrating a block diagram of SEM analysis module, using Security Sensitive Level (SSL), in accordance with an embodiment of the invention.

The Security Evaluation Module (SEM) is designated to implement the financial institution policy relating to authentication requirements, and to the extent (level) of the biometric authentication. In accordance with certain embodiments, the SEM (130) includes SEM analysis module (131) coupled to SEM Criteria Table (132). By this embodiment, the SEM analysis module will determine security measures according to a security sensitivity level (SSL) (133') and security criterion. The latter, by this particular embodiment, is constituted by one or more of the criteria set forth table (132). By the specific embodiment of Fig. 13, the specified criteria being: Customer profile (133) (for instance, customer with higher/lower credit), Operation sensitivity profile (134) (e.g. how "sensitive" is the transaction). The Operation Duration Complexity (135) refers to the complexity level of the transaction. For instance, transactions involving foreign currency may be considered more complex than transactions involving local currency (for the same monetary value), and accordingly customers may "understand" if more security measures requiring higher level of certainty will be applied in the case of that foreign currency is involved. EFSP - mode of operation (136) indicates the machine through which transaction is invoked. For instance, ATM may be regarded more secured than certain POS machines, and accordingly, higher level of security may be imposed in the case that POS machine is used. The CRAM information (137) defines additional information which may be considered, such as registration related data, where earlier registration data may be treated differently than later registration date. The EFSM related parameters (138) refers to parameters of the EFSM, such as the location of the EFSM (for instance an EFSM located in a bank is, on its face, more secured than an EFSM located in located in a mall. The EFSP network status (139) stands for parameters of the network, such as network load. For instance, the more loaded the network, the less security measures are applied. The transaction table (139') may define the type of the transaction, where different transaction types require different sensitivity level, e.g. withdrawing cash may require application of biometric data security measure, whereas inquiring balance of account does not require application of biometric test. By way of another non limiting example, certain transactions may require different sensitivity level. For instance, bank wiring between accounts of different customers, may require application of biometric data at a sensitivity level that prescribes higher level of certainty compared to, say, a transaction of bank wiring between different accounts of the same customer.

Note that the criteria of Fig. 12 and the pertinent example are provided for illustrative purposes only and are by no means binding. Note also that one or more instances of the criterion may be used. For example, two or more of the specified instances (e.g. any two of the specified 134 to 138 examples) may be used in order to determine the sensitivity level prescribing which measures to apply and to what extent. The security criterion and the SSL, prescribe which, from among the security measures, to apply (say, card data and PESf, but not biometric data, or in accordance with another embodiment card data and PESf and biometric data). In accordance with certain embodiments, the SSL may also prescribe the degree of certainty required in the application of one or more of the measures. For instance, it may prescribe the certainty degree of matching that is required to authenticate biometric data.

Consider the following example, assuming that the security criterion being the transaction type. Then, for transaction type that concern general market information, the sensitivity level may be very low, requiring only provision of card data. In the case of more sensitive transaction type, say inquiring the balance of account of the user, the security criterion may require higher SSL, now demanding to apply more security measures, say the card data and PESf. In the case of still more sensitive transaction type, say withdrawal of cash (up to $250), still higher SSL is requires, say requiring also biometric data which match at least in X% (i.e. X% match between the so received biometric data received by the user and the, a priori, reference stored data in the CBRA for this particular user (as received during registration phase). In accordance with still more sensitive transaction, say bank wiring of large amount from one account to the other, the specified card data, PESf and biometric data are required, however, now with Y%>X% of matching degree between the provided and reference pre-stored biometric data.

The invention is, of course, not bound by this particular example and other variants are applicable. By way of another non limiting example, the security criterion may take into account, in addition to transaction type, also the user profile, where users with better credit will be required lesser sensitivity compared to users with less credit.

As specified above, in accordance with certain embodiments, the system of the invention can be implemented as an add-on, on existing infrastructure. Thus, the EFSM can be a standard device, say ATM enhanced with DIS and BID modules. The ATM will still operate in a known per se protocol enhanced by extra fields to support the provision of biometric data.

The present invention has been described with a certain degree of particularity, but those versed in the art will readily appreciate the various alterations and modifications may be carried out, without departing from the scope of the following claims:

Claims

CLAIMS:

1. In an electronic financial system (EFS), a method for conducting a secured transaction in respect of a user, comprising

(a) receiving reference security measures that include encrypted PIN data, user identification data and biometric data of the user;

(b) receiving a request for the transaction;

(c) determining according to a security criterion and sensitivity level, the security measures that apply and comparing them to corresponding reference security measures for authenticating or not the transaction.

2. The method according to Claim 1, wherein said (c), comprising: receiving according to said security criterion selected security measures and comparing them to the reference security measures, according to said sensitivity, for authenticating or not said transaction.

3. An electronic financial system (EFS) for conducting a secured transaction in respect of a user, comprising a registration unit configured to receive security measures that include encrypted PIN data, user identification data, and biometric data; an end user unit configure to receive a request for the transaction, the unit being associated with security measures system that includes PIN module, user identification module and biometric module; a processor configured to communicate with said end user unit and security measures system for determining, according to a security criterion and sensitivity level, the security measures that apply; said processor is configured to communicate with said end user unit, for receiving said selected measures, and comparing them to corresponding reference security measures, according to said sensitivity, for authenticating or not said transaction.

4. The system of Claim 3, wherein said end-user unit includes an Automatic Teller Machine.

5. The system according to Claim 3, wherein said end-user unit includes a Point of Sale Machine.

6. The system according to Claim 3, wherein said end-user unit includes a workstation.

7. The system according to Claim 3, wherein said user identification module is configured to receive data extracted from a magnetic card.

8. The system according to Claim 3, wherein said user identification module is configured to receive data extracted from a smart card.

9. The system according to Claim 3, wherein the security criterion is at least one member from the group that includes: type of transaction, profile of the user, operation sensitivity profile, operation duration/complexity, EFSP mode of operation, CRAM information, EFSM related parameters and EFSM network status.

10. The system according to Claim 3, wherein said biometric module being an add-on module.

11. The system according to Claim 3, wherein said biometric module is configured to process the biometric data and comparing it to a reference biometric data.

12. The system according to Claim 3, wherein said processor is configured to process the biometric data received from said end user unit and comparing the data to a reference biometric data.

13. An electronic financial system (EFS) for conducting a secured transaction in respect of a user, comprising a registration unit for receiving security measures that include encrypted PIN data, user identification data, and biometric data, stored Central Biometric Registration and Authentication (CBRA) File; an end user unit configured to receive a request for the transaction, the unit being associated with security measures system that includes PIN module, user identification module and biometric module; a processor including a Central Registration/Authentication Module (CRAM) coupled to said end user unit and security measures system and configured to determine, according to a security criterion and sensitivity level, the security measures that apply; said processor is configured to communicate with said end user unit, for receiving said selected measures, and comparing them to corresponding reference security measures, using to said sensitivity, for authenticating or not said transaction, the communication between the end user unit and the processor is secured by Data and Information Security (DIS)

Module.

14. An electronic financial system (EFS) for conducting a secured transaction in respect of a user, comprising a processor configured to receive, through a communication link, from a registration unit security measures that include encrypted PIN data, user identification data, and biometric data; the processor is configured to receive, through a communication link, from an end user unit a request for the transaction, the processor is configured to determine according to a security criterion and sensitivity level, the security measures that apply; said processor is configured to communicate with said end user unit, for receiving said selected measures, and comparing them to corresponding reference security measures, using to said sensitivity, for authenticating or not said transaction.

15. In an electronic financial system (EFS) for conducting a secured transaction in respect of a user, comprising an end user unit configured to receive a request for the transaction, the unit being associated with security measures system that includes PIN module, user identification module and biometric module; the end user unit is configured to communicate to a processor through a communication link, for determining selected security measures, and communicating said selected measured to the processor through said link, for authenticating or not said transaction.

16. A computer program product that includes a storage for storing a computer code for conducting method steps implementing a secured transaction in respect of a user in an electronic financial system (EFS), the method steps comprising

(b) receiving a request for the transaction;

17. The method according to Claim 1, wherein said sensitivity level associated with the biometric data security measure, varies according to said security criterion.

18. The method according to Claim 17, wherein said security criterion includes transaction type, and said sensitivity level associated with the biometric data security measure, varies according to at least said transaction type.

19. The method according to Claim 3, wherein said sensitivity level associated with the biometric data security measure, varies according to said security criterion.

20. The method according to Claim 19, wherein said security criterion includes transaction type, and said sensitivity level associated with the biometric data security measure, varies according to at least said transaction type.