Patent Application
20120313754
Enterprises and governments are increasingly relying on smart cards to provide identity authentication of individuals, information, devices, and/or assets. Smart cards may house, and in some cases, process security information for securely validating the identity of individuals, financial accounts, assets, etc.
Certain governments are also issuing and considering smart cards for their citizens for identity validation purposes and for providing useful historical information about their citizens. Many states in the United States and many foreign governments now issue drivers' licenses in the form of smart cards, which include a variety of information about a respective driver, such as blood type, medical conditions, prior driving record, photograph of the driver, physical characteristics of the driver, etc. Smart cards are also used to conduct business transactions and securely activate other devices or assets, such as accessing bank accounts, activating a lock to a safety deposit box, and the like.
Most smart cards today require some form of activation and authentication to access confidential information included on the smart cards or to access confidential information in another location gained by use of the smart card. Authentication is generally the process by which an entity, such as a financial institution or other type of institution, identifies and verifies itself to users and vice-versa. Authentication may include the use of physical objects, such as cards and/or keys, shared secrets, such as personal identification numbers (PINs) and/or passwords, and/or biometric technologies, such as voice prints, photos, signatures and/or fingerprints. Biometric tasks may include, for example, an identification task and a verification task. The verification task may determine whether or not the individual claiming an identity is the individual whose identity is being claimed. The identification task may determine whether the biometric characteristic, such as a fingerprint or other biometric, matches that of someone already enrolled in the system.
Conventionally, biometric systems have a common methodology, regardless of their modality, such as fingerprint, face, retina, voice, or the like. A person may enroll by donating some number of samples of the respective biometric. From these samples, the biometric system may create a model of the particular individual's patterns, which is referred to as a template. When the person attempts to access the system, the application collects new data. In a verification application, the individual may claim an identity, and the application retrieves the individual's model from a database and compares the new signal to the retrieved model. The result of this comparison is generally termed a match score indicating how well the new signal matches the template. The application then compares the match score obtained with a pre-defined threshold and decides whether to allow or deny access to the individual or, for example, to ask the individual for more data.
Various authentication parameters may be employed by security systems to verify a valid cardholder and to grant the cardholder access to a secured resource. Information parameters, such as PINs, may be read and processed by a card reader according to a system verification algorithm. However, information can be compromised, so that many authentication systems also require person-unique biometric parameters, such as fingerprints, retinal images, and the like. In such authentication systems, cardholder bio-specimens are conventionally stored in a system or host computer. Conventionally, during authentication the host computer obtains the information parameters, for example, from the card, and the biometric parameters from the person and matches both to the system-stored values. For a fingerprint, for example, there may be fourteen points and interpoint distances that the biometric reader compares and, depending on the match score, grants or denies access.
While various smart card interface devices and terminals are available today that can be used to support smart card, biometric, PIN entry, and/or challenge and response methods for multi-factor authentication, the host-based software controls the entire process for each method of authentication. For example, PC/SC Workgroup specifications Parts 1 through 10 the entirety of each are incorporated herein by reference, have been defined to support personal computer or host-based software in controlling the interactions with Smart Cards (ICCs) and Smart Card readers (IFDs). These PC/SC specifications provide for interoperability but do not relieve the host-based system from controlling the entire process of interaction with smart cards and provision of key security functions.
Thus, it is desirable to provide key security functions such as biometric authentication and PIN Code entry internally (i.e., on the device) while still retaining PC/SC compliance for interoperability.
Accordingly, there is a need for a system and method for verifying the identity of an individual. The method may include for a smart card interfaced to a biometric interface device, determining if a match-on-card application exists on the smart card as a function of information contained on the card and capturing a biometric of an individual if a match-on-card application exists on the smart card using the biometric interface device. The captured biometric is then compared with a stored biometric. If the captured biometric matches with the stored biometric then a host application may be notified that the individual has been verified to access the data. Any one or several of these steps are performed without the use of a host application.
In another embodiment of the present subject matter a method is provided for authenticating a user of a smart card. The method may include capturing a biometric of the user using a biometric interface device and creating a template file from the captured biometric. The created template file may then be compared with stored template information. If the created template file matches with the stored template information then a host application will be notified of the existence of a verification. Any one over several of these steps are performed without the use of a host application.
In yet another embodiment of the present subject matter a method for verifying an identity of a user of a smart card is provided. The method may include capturing a biometric of the user and verifying the identity of the user as a function of a comparison of the captured biometric to a stored template of a corresponding biometric. These steps may be performed without the use of a host application.
A further embodiment of the present subject matter provides a smart card interface apparatus having an electronic enclosure, a display on the electronics enclosure, and a biometric device for capturing a biometric of a user of a smart card. The apparatus further includes circuitry contained in the enclosure and having stored thereon one or more programs for processing a captured biometric of the user, for creating a template file from the captured biometric, for determining if a match-on-card application exists on the smart card, for comparing the created template file with stored template information, and for notifying a host application of the existence of a verified biometric if the created template file compares to the stored template information within a predetermined threshold. At least one of the one or more programs function without the use of a host application.
These and other embodiments of the present subject matter will be readily apparent to one skilled in the art to which the disclosure pertains from a perusal or the claims, the appended drawings, and the following detailed description.
With reference to the figures, where like elements have been given like numerical designations to facilitate an understanding of the present subject matter, the various embodiments of a biometric smart card reader and method are described.
The phrase Smart Cards and acronym ICC are used interchangeably in this disclosure and such use should not limit the scope of the claims appended herewith. Further, the phrases and Smart Card readers/devices and acronym IFDs are used interchangeably in this disclosure and such use should not limit the scope of the claims appended herewith.
Generally, an ATR is a series of signals sent out by a respective smart card when the card is powered up and reset for the first time (cold reset) or subsequently reset (warm reset). A cold reset may cause a primary ATR to be returned, a warm reset may cause a secondary ATR to be returned. ATR signals form bytes whereby the term signal is used to stress that an actual protocol to be used is undefined at this point within the communication. There are a number of low level handshaking steps that take place, during the power-up and ATR cycle, which will establish a protocol to use. The ATR itself is split into two blocks, a first block containing interface characters (bytes) and a second block containing historical characters (bytes). The final character in an ATR is an optional check character or TCK.
Interface characters are generally used to define operational parameters for a smart card. Information such as allowed protocols, voltage levels, class of smart card, and speed at which a clock frequency may be run may be conveyed as part of exemplary interface characters. The ISO 7816 specification provides timings and voltage levels that should be used when reading the ATR and thus interface characters are defined within this specification. Historical characters, however, are not defined by the ISO 7816 specification. Historical characters may include up to fifteen bytes of data which may be smart card or application specific. The number of historical characters may be defined within the interface characters to inform a respective IFD of how many bytes to expect. Interpretation of the historical characters, however, is left to an IFD application. Historical characters are often used to convey easily accessible information, such as, the amount of value currently held on a card. This information may thus enable a simple device (e.g., a Key Fob reader) to reset the card and display the value on the respective purse by only reading the historical characters. In embodiments of the present subject matter, the information contained in the ATR historical characters may be smart card specific and may contain a value informing a device 100 that the card contains a supported match-on-card (MOC) application (i.e., an on-card application that compares (matches) a captured biometric with a biometric reference pre-stored on the card). Of course, additional information may be contained in exemplary ATR historical characters including, but not limited to, information about the card manufacturer, the chip, masked ROM in the chip, the card life cycle state. Alternatively or additionally, one or more bytes of the historical characters may be used to indicate the MOC application installed on the smart card (ICC). The value may also inform the device 100 which application should be run on the smart card or may indicate that a EFDIR file should be referenced to find the proper MOC application to be run on the smart card. A typical structure of an EFDIR file is defined in ISO 7816-4 and 7816-5, the entirety of each being incorporated herein by reference.
For example, in one embodiment the ATR string may be used to determine the type of smart card 115 inserted into the device 100. Activation and operation of a smart card is generally governed by ISO 7816 standards, the entirety of which are incorporated herein by reference. During step 452 the device 100 may determine if a support MOC application exists on the smart card 115. With receipt of the ATR string, the device has specific information about the capabilities of a card and how to send commands and receive replies from an operating system (OS) and/or smart card applications. This information may allow the device 100 to directly interact with the smart card 115 to determine if a supported MOC application exists.
Of course, the ATR string is exemplary only and is but one of several sources of information used in embodiments of the present subject matter to determine if a MOC application is resident on the smart card 115. For example, at least two other, non-limiting sources may be an ATR File and a directory (DIR) File.
An ATR File may include a default elementary file identifier (FID) of ‘0x2F01’ and may include a customized ATR string. In one embodiment, a ‘2F01’ file may include additional data for the ATR and may be an extension to the historical characters which are limited to 15 bytes. The content of this file, whose structure is not defined by the ISO/IEC standard, may be ASN.1-coded. The parameters in the ATR file or the historical characters may contain complex information relating to the smart card and the operating system used in the card. For example, the parameters may indicate which file selection and implicit selection function are supported by the smart card and provide information about the logical channel mechanism. These parameters may also hold additional information about the card issuer, the card and chip serial numbers, the ROM mask version, the chip and the operating system. The coding of the relevant data objects may be defined in the ISO/IEC 7816-4 and 7816-5 standards. According to ISO/IEC 7816-4, the historical characters may also contain the following three data fields: an obligatory category indicator, one or more optional data blocks in compact TLV format, and an optional status indicator. The compact TLV format may have a tag in the first nibble and the length of subsequent data in a second nibble. The category indicator may be transferred in T1 and may include information about the structure of the data in the ATR. The data following the category indicator may include information about the services supported by the smart card operating system and the operating system functions. The ATR File may contain any necessary data to permit a device 100 to know that a smart card contains a supported MOC application or any other key information that the device 100 would need to authenticate the card/card holder correctly. In another embodiment, the ATR File may include one 36 byte record and changes to the ATR historical bytes may come from information in the ATR File. Information in the ATR File may thus denote the presence of a MOC application, and the identified application may either be defined or assumed by the device 100 based upon the information returned.
A DIR File may be an elementary file defined in the ISO/IEC 7816-5 standard with a file identifier of ‘0x2F00’ and found in the root directory of the smart card file system. Generally, a ‘2F00’ structure is a linear fixed structure having n bytes. Table 1 below provides one exemplary, non-limiting ‘2F00’ structure.
The contents of this linear file may, in one embodiment, be read to determine if any of the AIDs denote a supported MOC application. If a supported MOC application is found, the device 100 may begin a biometric capture and compare processes. Objects (or records) may include an AID, an optional path to the directory and/or application files, and/or control commands for each application on the smart card. Thus, entries in the DIR file may be read to determine if a supported MOC application exists on the smart card and where and how to initiate the application.
Any of these options for determining the presence of a MOC application may be employed in step 452 by an exemplary device 100 to set a value indicator for the decision to be made during this step. For example, if the value indicates that no MOC application exists (or is recognized as such) for supporting biometric authentication, then it may be determined in step 459 whether the device 100 is presently attached to a host computer system. If the I/O connection is active, then in step 460 an insert event and/or ATR string may be provided to the host computer system through the supported I/O connection and, in step 461 the device 100 may then be under the control of a host application. Host applications may then send commands and receive replies to smart card applications stored and run on the smart card 115 inserted into the device 100.
If, in step 452, the value indicator denotes a MOC application for supporting biometric authentication then, in step 453 applicable processes may be performed that are required for biometric authentication. These processes would be not be under the control of a host application. For example, in step 453 a biometric sample may be obtained by a device 100 and compared by the device 100 or smart card 115 against a previously obtained biometric sample stored on the smart card 115. If the two samples are likely matches (e.g., using a predefined/stored threshold or template and denoting a successful match) then the biometric may be considered as verified. Of course, different and/or multiple types of biometrics may be obtained with devices 100 according to embodiments of the present subject matter. For example, a camera may be used to capture a facial or retinal image, a microphone may be used for voice recognition and/or a fingerprint sensor may be used to capture a fingerprint. The embodiments described herein may also include a silicon area sensor for capturing a fingerprint image from a stationary finger. Silicon swipe sensors and optical sensors may also be employed for the same purpose. Exemplary fingerprint sensors include, but are not limited to, SmartFinger film fingerprint sensors, TouchChip fingerprint sensors, and other known silicon or polymer-based fingerprint or swipe sensors. Once a biometric, in this case a fingerprint image, has been captured by the fingerprint sensor a template may be generated with image or minutiae data. The device 100 may then generate a “Verify” statement send this command and template data to the MOC application stored and run on the Smart Card ICC. The MOC application would then compare the template provided with a previously enrolled template stored on the smart card 115 and determine if the two templates match to an extent it would consider a positive or likely match.
In step 454, if the biometric was determined to be “Verified” (e.g., successfully matched against the previously stored biometric template), then it may be determined in step 459 whether the device 100 is presently attached to a host computer system. If the I/O connection is active, then in step 460 an insert event and/or ATR string may be provided to the host computer system through the supported I/O connection and, in step 461 the device 100 may then be under the control of a host application.
If the biometric was determined not to be “Verified” in step 454, then it may be determined if a retry limit has been reached. Generally, a retry limit corresponds to a counter which identifies the number of times authentication has been attempted. If the retry limit has been reached, a message may or may not be displayed in step 456 regarding that the limit has been reached. Further, if the retry limit has been reached, power to the device 100 may be secured and/or the device 100 otherwise turned off in step 458. In one embodiment, the smart card 115 may be returned to the user if inserted into a respective slot of the device 100 and then the device 100 turned off. If the retry limit has not been reached, then the user may be prompted to provide another biometric sample in step 457. Of course, any one or several of the captured biometrics during this iterative process may be different and multiple biometrics may be employed during any one or several iterations.
While biometric authentication through a MOC application has been discussed above, the same or similar process may be employed to perform PIN Code verification or both biometric and PIN code verification. Further, the ATR string, ATR File, and DIR file may also define more than one authentication process that needs to be completed before the smart card is available for receiving commands from an host application.
Conventionally, certain steps described above and illustrated in
Connected to the ICC resource manager 503 are IFD handlers 504 which encompass the PC software necessary to map native capabilities of an IFD 500 to an IFD handler interface. The IFD handler 504 is typically low-level software within the PC that supports specific I/O channels used to connect the IFD 500 to the PC and provides access to specific functionality of the IFD 500. This is the layer of the interoperability specification primarily responsible for facilitating the interoperability between different IFDs 500. The IFD 500 corresponds to an exemplary device described herein and may be the interface device through which ICCs 505 communicate with a PC. The IFD 500 may provide DC power to the respective microprocessor chip, may provide a clock signal used to step a program counter of the microprocessor, and may provide an I/O connection (wireless or wireline) though which digital information is passed between the IFD 500 and ICC 505. Exemplary IFDs 500 may have one or more slots to read ICCs 505 and may also support extended capabilities such as display or PIN pad, to name a few. In one embodiment, an IFD 500 may support a card insertion notification event and/or a card removal notification event. Thus, when one of these events occurs, it may be the responsibility of the IFD Handler 504 to appropriately notify the ICC Resource Manager 503. In one embodiment of the present subject matter, the card insertion notification may be withheld until the respective biometric MOC has completed with a positive or “authenticated” result. Exemplary IFDs or devices 500 may thus be considered PC/SC compliant and provide unique features to support biometric, PIN code and/or challenge response authentication prior to placing itself under control of a host application (e.g., ICC Aware Applications 501). This capability may thus relieve the ICC Aware Application 501 from controlling the process of enrollment of biometric samples, template creation, and matching biometric template. Embodiments of the present subject matter may thus provide the ICC Aware Application 501 with a higher level of access control security without having to be involved in providing this capability.
For example, another MOC process may include enrolling or storing one or more biometrics for a cardholder whereby such information is stored on a smart card as a template. Any additional personal or confidential data may also be stored on the smart card. The cardholder's smart card may then be placed in a reader which will then prompt the person to present a previously enrolled biometric. At this time, an exemplary system may provide information about the person, depending upon the application, and the live biometric is read and analyzed. When compared, if the biometric from the person and the template on the card match, the identity of the cardholder has been verified. The system may then perform any requested actions such as uploading confidential data, etc. If the information does not match, the requested action may be rejected and the true cardholder's credentials protected from fraud or misuse.
In step 920, a template file may be created from the captured biometric, and the created template file may then be compared with stored template information at step 930. In one embodiment, the stored template information may have been created during a biometric enrollment process for use in subsequent comparison processes. In step 940, if the created template file matches the stored template information, then a host application may be notified of the existence of a verification. In another embodiment, step 940 may include authorizing the user to access information on the smart card, on a host device, at a host entity, or combinations thereof. Of course, any one or more of steps 910-940 may be performed without the use of a host application. In a further embodiment, if the created template file does not match the stored template information, then the method 900 may include at step 950 determining if a retry limit has been reached. In the event at step 960 that the retry limit has not been reached, then any or each of the preceding steps may be repeated until the created template file matches the stored template information (i.e., a positive comparison) or until the retry limit has been reached. If the retry limit has been reached, then the biometric interface device may be secured. Of course, any one or several of the captured biometrics during this process may be different and multiple biometrics may be employed during any one or several iterations. Further, any one or both of steps 950 and 960 may be performed without the use of a host application.
It may be emphasized that the above-described embodiments, particularly any “preferred” embodiments, are merely possible examples of implementations, merely set forth for a clear understanding of the principles of the disclosure. Many variations and modifications may be made to the above-described embodiments of the disclosure without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and the present disclosure and protected by the following claims.
Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more program products, i.e., one or more modules of program instructions encoded on a tangible program carrier for execution by, or to control the operation of, a data processing apparatus. The tangible program carrier can be a computer readable medium. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, or a combination of one or more of them.
The term “processor” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The processor can include, in addition to hardware, code that creates an execution environment for the program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.
A program (also known as a computer program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).
The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
Processors suitable for the execution of an exemplary program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both.
While this specification contains many specifics, these should not be construed as limitations on the scope of the claimed subject matter, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.
Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.
As shown by the various configurations and embodiments illustrated in
While preferred embodiments of the present subject matter have been described, it is to be understood that the embodiments described are illustrative only and that the scope of the invention is to be defined solely by the appended claims when accorded a full range of equivalence, many variations and modifications naturally occurring to those of skill in the art from a perusal hereof.
The present application is co-pending with and claims the priority benefit of the provisional application entitled “Biometric Smart Card Interface,” Application Ser. No. 61/496,132, filed on Jun. 13, 2011, the entirety of which is incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61496132 | Jun 2011 | US |
