A Mobile Biometric System-On-Token System for Signing Digital Transactions

Mobile Device Security

MARCH/APRIL2010■1540-7993/10/$26.00©2010IEEE■COPUBLISHEDBYTHEIEEECOMPUTERANDRELIABILITYSOCIETIES 13

RicaRdo Ribalda, GuilleRmo González de RiveRa, ánGel de castRo, and JavieR GaRRido

Universidad Autónoma de Madrid

I n some scenarios, systems must authenticate users on the basis of “who they are” instead of “what they own or know.” Biometrics have emerged in the past decade as a well-hyped alternative

for applications that must automatically authenticate people. Certainly, biometrics are attractive for users (forget about PINs and passwords, you are your own key) and useful for agencies (get identity results from a fingerprint database search in minutes) . However, we can’t forget that—as with any technology aiming to provide a security service—biometric systems are vul-nerable to external attacks that can compromise their integrity. So, it’s especially relevant to understand the threats to which they’re subjected and analyze their vulnerabilities to prevent possible attacks and increase user benefits.1

Although biometric verification is several years old, its implementation in the real world as a substitute for keys or passwords isn’t so extensive. Before it can be implemented globally, we must solve some new prob-lems and revisit old ones. Formal biometric systems present a critical issue: users can’t revoke biometric patterns because they are born and live with them. If such patterns are compromised, an impostor could ex-ploit any working system the user has access to. On the other hand, legacy passwords or keys can be revoked or changed by the user if they’re compromised. Fur-thermore, no biometric technique is applicable to the whole population. Even techniques as mature as finger-print recognition are unusable by some people, owing to physical problems (such as amputations) or sensing problems (such as the absence of enough sweat in the finger pores that capacitance sensors can’t mea sure it).

The technical and privacy problems of the legacy biometric systems keep many people from embracing biometry as an authenti-cation solution.2

The System-on-Token architecture that we pro-pose overcomes these problems, giving the user full control over his or her personal data. To demonstrate its feasibility, we implemented it on a commercial de-vice, a Nokia N800 (see Figure 1).

We conducted our research following the security-through-transparency principle—largely applied in other security-related areas such as cryptography—which pleads for making security systems as public as possible. This paradigm takes the approach that vul-nerabilities exist regardless of their publication, so we should show the internals to the community and work together to find flaws and improve them. More than controlled risk, we believe that a community is more capable of finding a flaw than a single company. This isn’t to say that obscurity can’t provide any protection, but rather that the protection is out of our control and probably temporary. We believe that to make biomet-ric devices and applications secure, we must understand and assess the threats and publicly report the internals and the results of the evaluations in order to issue effec-tive technical and procedural countermeasures.

Basic Biometric SystemsBiometric systems have been implemented with rela-tive success in big corporations that need to control who enters a door or validate critical actions, for ex-ample. For the former, a sensor at a door’s entrance is connected to a database containing users’ biometric

The System-on-Token architecture for biometric systems

gives users full control over their biometric data and

lets them sign digital transactions using biometrics. The

authors implemented and tested the architecture on a

commercial mobile device, the Nokia N800.

AMobileBiometricSystem-on-TokenSystemforSigningDigitalTransactions

Authorized licensed use limited to: Kalpataru Institute of Technology. Downloaded on August 03,2010 at 08:57:22 UTC from IEEE Xplore. Restrictions apply.


14 IEEESECURITY&PRIVACY

patterns. After a user enters his or her information (via a fingerprint scan, for example), the sensor sends the data to the database for matching. A system for validating critical actions is similar, but the sensor is located on the user’s desk.

The typical biometric system consists of a huge biometric database and one sensor per application or access. In such a scenario, attackers can compromise biometric patterns at many points, as Figure 2 shows. The most obvious is compromising the database itself. To overcome this problem, the system designer should encrypt the templates on the database.3 Unfortunate-ly, doing so can deteriorate the system’s quality.

Another issue is that if no active control exists for the system’s sensors, attackers can manipulate them or replace them with fakes to steal users’ personal data (such as with false ATMs used in banking, or credit-card skimmers). Such data travels over communica-tion lines to accomplish matching; system designers must take extreme care to protect that data from sniff-ing or spoofing. Finally, every sensor should work with all possible users, which necessitates including multimodal sensors. As you might imagine, this clas-sical approach is useless for a globalized transaction-signing system. Every market and computer in the world should have an audited, multimodal sensor for authenticating every customer.

To overcome problems inherent to unique biomet-ric databases, the biometrics industry has proposed architectures such as match-on-token (see Figure 3) or template-on-token.4,5 In these architectures, all us-ers hold a token with their biometric data that never leaves them. Although this solves problems related to database and communication security, the same sen-sor vulnerabilities still exist. As in the previously de-scribed system, the user must provide biometric data to the system, trusting any sensor in it, and one sensor should exist for every modality involved (for example, fingerprint readers, cameras, and microphones that will work with the whole population).

Industry researchers have developed an evolved version of the match-on-token architecture, called the sensor-on-token or fingerprint card, in which the user has a smart card with a fingerprint sensor.6 This solution also has its problems. The user must trust that the card is secure because almost no information exists about what algorithms are at work in it or their quality. These systems are developed to be as obscure as bank smart cards, whose insecurity has been demonstrated even in those that are state-of-the-art.7

The number of biometric modalities that can run on a smart card is reduced—that is, it’s difficult to add a microphone, camera, or fingerprint sensor to a credit card. Integrating physical sensors into them is extremely difficult, mainly because smart cards must fulfill a strong standard regarding size.

Figure 1. The Nokia N800. We implemented our System-on-Token biometric

architecture on this device to demonstrate the architecture’s feasibility.

Featureextraction

Sensor

Matching

Authenticationdevice

Weak points

Output

TemplateUser

template

Database

Protectedresource

Figure 2. Classical biometric architectures. Such architectures have several

possible attack points.

Featureextraction

Sensor

Authenticationdevice

Weak points

Output

Template

Usertemplate

Smartcard

Matching

Protectedresource

Figure 3. The match-on-token architecture. This architecture solves problems

related to database and communication security in biometric systems but

doesn’t address sensor vulnerabilities.



www.computer.org/security 15

In 2002, at least 15 companies were developing smart cards with sensing or matching capabilities,6 but as of mid-2008, none had released an actual prod-uct, to our knowledge. Only one system in the litera-ture is close to the one we propose here. That system, SecurePhone, can conduct sensing and matching on the actual device (www.secure-phone.info). The main differences between our architecture and the SecurePhone is that the SecurePhone isn’t meant for interconnection, only works in one device, and is a closed solution.

X.509 Digital CertificatesToday, people can conduct much official business re-motely thanks to digital certificates.8 An official or-ganization issues an RSA certificate that lets the user sign digital transactions anywhere in the world with a computer. In many countries, this digital signature has the same legal validity as a physical one.

This kind of security model follows the classic idea of “what you own” and “what you know.” How to store this certificate safely is the user’s problem. It’s common to protect it with a passphrase or save it on a smart card with a PIN. Of course, the system will rec-ognize an attacker with access to this certificate as the real person. If users believe their certificate has been compromised, they can revoke it. To ensure a system’s integrity, users (or a hired auditor) can also check the infrastructure’s internals, which are public.

The System-on-Token biometric architecture we describe next lets us add biometric authentication to the certification process.

System-on-TokenThe biometric System-on-Token consists of a mobile system (token) the user carries that can accomplish all the tasks required of a biometric system:

• sense biometric parameters,• extract features, and• match extracted features with the original features,

delivering a yes/no answer.

In addition to conducting functionalities common to any biometric system, the token should be able to communicate with the outside world in a secured, authenticated way and provide the user with straight-forward information about what he or she is accept-ing. A transaction’s output is just a signed reply without biometric information. The token can be any device with sensing, processing (as with fingerprint sensors or cameras), and communication capabilities (such as the Global System for Mobile Communications [GSM]).

System-on-Token is a step further than match-on-token and a natural evolution of the fingerprint card mentioned previously.

Proposed ArchitectureOur architecture (see Figure 4) is built on a hard-ware platform with light requirements—that is, we don’t need a high-end PDA or computer to use it—and some software packages. It can work on any hardware platform with sensing capabilities and one or more communication interfaces. End users can download and install the software packages onto their mobile platforms.

System-on-Token comprises three modules. The system core is the main module controlling the whole system. It handles requests from the outside world and interacts with the user and other system modules. The certification module handles the user’s private and public keys and the public-key chain. It’s critical to the system and requires antitampering protection. Fi-nally, the biometric module senses and extracts features and authenticates the user using the personal charac-teristics in the device (such as fingerprint minutiae). It has a common API, and users can select from among different modules depending on their security re-quirements or handicaps, or the biometric modality selected (for example, fingerprints, voice recognition, or iris scanning).

The system core and the certification module are completely open and auditable. End users or exter-nal auditors can obtain them from open repositories. The system core is available for the most representa-tive mobile platforms or operating systems, and end users or mobile companies can easily port it to other systems, provided they leave the source code available for audition. Users can download the biometric mod-ule from third parties, or they can design it for a spe-cific sensor. The vendor can release its code or leave it closed, and end users are able to choose from among different vendors/providers.

This architecture provides an extensible, open, and

Extractfeatures

SenseRequestveri�cation

Vendorcerti�cate

Token

1 3

4 5

Signedreply

Signedrequest

Usertemplate

Usercerti�cate

Signrequest

Protectedresource

Match

Figure 4. Our System-on-Token architecture. This architecture lets us add

biometrics to the X.509 certificate.




secure framework in which different groups can in-teract to give users a biometric solution that works on multiple operating systems and hardware platforms.

Mode of UseThe architecture provides three basic functions. We’ve designed them all with security in mind, and they pro-vide a secure and auditable transaction system compat-ible with the legacy X.509 certificate infrastructure.

Transaction. Transactions are the basic function in Sys-tem-on-Token and should have the same legal validity as a signed contract between vendors and users. Figure 5 illustrates this mode (an arrow implies data transfer).

The vendor starts the transaction by sending an inquiry to the user. The user’s device processes this transaction, verifying the user’s identity and giving as a result a reply the user has signed. Neither the bio-metric parameters nor the certificate leave the device.

Adding a biometric module. To provide a flexible so-lution in which users can choose from among different biometric algorithms, the system should be extended with third parties’ biometric modules. Our System-on-Token architecture provides a secure method for this action. As mentioned, users can download a bio-metric module from a third party they trust and enroll themselves in this new module once it’s installed. If the deployment is correct, the module will acknowl-edge the third party for possible charging or tracking.

Adding a public key. The user’s device can interact with other vendors or third parties only if it recog-nizes their public keys. The system provides a way to

securely and easily add such keys to the certification module key chain: the user must download the ven-dor’s public key. As long as a certificate authority (CA) has correctly signed this public key, it’s added to the certificate module key chain.

ImplementationTo implement the System-on-Token architecture on a mobile device, we must take into account some im-portant concerns:

• Integrating the sensor into the device. Manufactur-ers are increasingly adding biometric sensors to their devices, but if no available sensor exists on an em-bedded device, users can add one using an expan-sion port, such as USB. If this isn’t possible, users might consider using nonspecific biometric sensors (such as low-quality integrated cameras9).

• Integrating the biometric module into the system. Biomet-ric algorithms, especially feature extraction, tend to be complex and hard to optimize. Consequently, match-on-token devices leave feature extraction to the host, a process that requires considerable com-putation and memory. To conduct this process on an embedded device, biometric modules’ providers should either reprogram or optimize it with perfor-mance in mind.

• Integrating the certification module into the device. Strong cryptography relies on complex algorithms. For-tunately, mobile providers can easily optimize these algorithms in hardware, either using a field- programmable gate array (FPGA) or specific crypto- ASICs (application-specific integrated circuits).

To solve these issues, users must take special care in selecting a device, and providers in designing the bio-metric and certification modules.

Device SelectionTo implement our System-on-Token architecture, we’ve selected a Texas Instruments OMAP proces-sor—a mixed ARM+DSP (digital signal processing) solution. The company developed this processor specif-ically for mobile devices, and it has a low-power profile. Developers can optimize signal-processing algorithms using the integrated DSP. Many mobile phones use the OMAP processor. Among them, the most interesting one is the Nokia N800 and its evolutions. These de-vices are part of an open source project called Maemo that provides full source code for modification, giving developers full control over the device.10

The Biometric ModuleWe ported a well-known fingerprint verification algo-rithm to the N800 device. We’ve selected the US Na-tional Institute of Standards and Technology (NIST)

Transaction(signed by vendor)

Signedtransaction Verify use

Verify data

Sign transaction

Userfeatures

SignedtransactionOkayData +

signature

7. OkaySystem-on-Token core

Certi�catemodule

Biometricmodule

CAkey

Userkey

Vendorkey

Printtransaction

1 10

5

24

9

6

3

8

Figure 5. Transaction flow. We can see the secured transaction between a

vendor and a client.




Biometric Image Software (NBIS). Because the N800 doesn’t have a fingerprint sensor, we connected an ex-ternal optical fingerprint sensor to it via USB.

NBIS comprises two sub-modules: mindtct for feature extraction and bozhort for feature matching. It was developed completely in C/C++, and develop-ers can obtain its source code on request from NIST.

We must recompile NBIS for any architecture dif-ferent than the i386 (standard PC). Unfortunately, the software wasn’t developed with multiple architectures in mind, so some parts of it (such as image-type de-tection) are dependent on the processor’s architecture.

To test the module’s speed, we used a database consisting of fingerprints from 36 different users. We obtained these images with the N800 using the same optical sensor used in the BiosecurID database.11

During module development, we had two require-ments in mind: the algorithm accuracy couldn’t de-teriorate, and the device needed to characterize and match a fingerprint in less than 2 seconds.

Feature ExtractionThe mindtdt sub-module is the most computation-ally expensive part of NBIS and determines the minu-tiae of a fingerprint using an image as input.

Our tests have shown that a processor-architecture-independent version of NBIS compiled with the stan-dard NBIS options for the Nokia N800 takes more than 5 seconds to extract an image’s features, com-pared to 0.1 seconds for a normal PC. As previously stated, this is far from our two-second requirement.

Our initial optimization effort focused on choos-ing the compiler flags carefully. The NBIS package recommends compiler flags that result in very slow execution for the selected device. After choosing the optimum compiler flags, feature extraction improved up to 471 percent.

To further improve feature-extraction speed, we pro-filed NBIS to find the most time-consuming functions; consequently, we redesigned two functions: dirbina-

rize contained a division by two that we substituted with a binary shift, and we optimized the function math_first_pair by substituting a linear search with a hash search. These modifications improved the feature extraction speed 9 percent without losing accuracy.

Further tests revealed that an image’s size and reso-lution are directly related to processing time. We ana-lyzed 16 fingerprints for minutiae, then shaved these same images (reduced them, while keeping the center of the image) and resized them (reducing the resolu-tion). Table 1 shows the results. As we expected, shav-ing or resizing reduces processing time.

MatchingThe bozorth3 module compares two minutiae files obtained with mindtdt and provides us with a score that determines their similarity.

Our tests have shown that a processor-architec-ture-independent version of NBIS compiled with the standard NBIS options for the N800 takes 0.062 sec-onds to calculate a score. We can improve this using the minutiae files from reduced images. Table 2 shows the results of tests we conducted from 1,296 match-ings. Shaving the image decreases the matching time,

Table 1. Feature extraction speed for 36 fingerprints.

Image processing (%) Average number of minutiae Average time consumed (ms) Relative speed (%)No processing 53.8 1,819 100.0

Resize 90 52.7 1,570 115.8

Resize 80 53.1 1,294 140.5

Resize 70 51.3 1,074 169.3

Resize 50 29.0 760 239.3

Resize 30 2.5 415 438.2

Shave 10 40.7 1,497 121.5

Shave 20 23.8 991 183.4

Shave 30 9.7 579 314.0

Shave 40 1.3 245 742.3

Table 2. Matching speed for 1,296 matchings.

Image processing (%)Average time

consumed (ms) Relative speed (%)No processing 92.5 100.0

Resize 90 109.0 84.9

Resize 80 172.7 53.5

Resize 70 173.3 53.4

Resize 50 173.6 53.3

Resize 30 12.7 725.9

Shave 10 58.8 157.3

Shave 20 33.3 278.0

Shave 30 15.5 597.5

Shave 40 12.6 734.8




as expected. However, resizing the image increases this time; this increase is much smaller than the time saved in the feature extraction, however, so the total time is significantly reduced in both cases.

The Certification ModuleFor the certification module, we used a modified ver-sion of OpenSSL,12 an open source implementation of the most common cryptographic systems, including Secure Sockets Layer (SSL), X.509, SMIME, and DSA/RSA. We selected this software because we can obtain and review all its source code. OpenSSL contains func-tions for hashing, encrypting, and decrypting.

We’ve developed tests to determine the time need-ed to validate a certificate, validate a signed transac-tion, and sign a transaction. We conducted all the tests using a legal X.509 Spanish signature from the FNMT (Spanish Bureau of Engraving and Printing). Table 3 shows the results.

AccuracyAlthough it improves validation and matching time, reducing fingerprints’ resolution or shaving them re-duces the algorithm’s accuracy.13 As Figure 6 shows,

the equal error rate (EER) is a function of the time needed for a complete operation. So, it represents the system’s correctness (quality) as a function of the time needed to validate a certificate and a transaction signed with that certificate, extract a fingerprint’s fea-tures, match the user, and sign the transaction.

With the proposed system, users can choose be-tween accuracy or speed. In our experiments, a re-sizing up to 80 percent or shaving 10 percent keeps the EER under 4 percent, compared to the initial 2 percent without resizing or shaving, whereas the total time decreases roughly 20 percent. These EER numbers might not be acceptable for some applica-tions, but these results at least act as proof of con-cept. The reader must take into account that the best EER result with the generic NIST algorithm is 2 percent. Using other, more specific algorithms and platforms with higher processing capacity would im-prove EER.

Possible AttacksThis system, as with any other biometric system, can be attacked using fake biometric characteristics, such as “gummy fingers.”14 Nevertheless, to positively sup-plant the user, an attacker needs to not only fake the user’s biometry (as with present systems) but also phys-ically access the device.

Because most of the security relies on the X.509 certificate in the device, an attacker could tamper with it to extract this certificate. However, this has its own problems. The attacker must overcome the device’s security and then obtain the passphrase that protects the certificate, which only the user knows.

Another attack would be to intimidate the user. In this case, we can still protect the system in two ways. First, some biometric systems detect stress to the user and deny access in such cases. Additionally, the system can implement a panic passphrase that will look correct to the attacker but doesn’t complete the transaction.

Finally, the system’s weakest point is user misuse. Given that all the decisions rely on the user, he or she could eventually remove all the biometric tests in the system. Because the basis of this system dictates that security ultimately be up to the user, there’s nothing the architecture can do but notify the user that his or her configuration isn’t secure.

T he System-on-Token architecture provides a solid alternative for credit cards and an easy way to hard-

en electronic transactions’ security via biometrics. In the future, we would like to see the system ported to more platforms, improving its universality. Biomet-ric systems providers will implement more biometric modules, giving the system even more security. We’re

Table 3. OpenSSL speed.

Function Time consumed (sec)Hash and sign 102 bytes 0.13

Hash and sign 104 bytes 0.14

Hash and sign 106 bytes 0.30

Verify 102 bytes 0.02



Verify a certificate 0.07

1

10

100

1,000

0.4 0.8 1.2 1.6 2.0 2.4Transaction time (sec)

EER

(%)

Resize

Shave

40%30%

20%

10%

0%100%

90%80%

70%

50%

30%

Figure 6. Equal error rate (EER) vs. transaction time. The accuracy of the

system is reasonable even with reduced processing times.




studying how to improve its tamper-resistance in the near future.

AcknowledgmentsThis work has been supported by the Spanish Ministry of Education and Science (MEC) under project TEC2006-13141-C03-03. Ricardo Ribalda is supported by an Educa-tion of University Teachers (FPU) fellowship from the MEC.

References1. A. Adler, “Vulnerabilities in Biometric Encryption Sys-

tems,” Proc. IAPR Audio and Video-Based Biometric Per-son Authentication (AVBPA 05), LNCS 3546, Springer, 2005, pp. 469–472.

2. I. Buham and P. Hartel, The State of the Art in Abuse of Biometrics, CTIT tech. report TRCTIT-05-41, Univ. of Twente, 2005.

3. A.K. Jain, K. Nandakumar, and A. Nagar, “Biometric Template Security,” EURASIP J. Advances in Signal Pro-cessing, special issue on pattern recognition methods for biometrics, vol. 2008, 2008, pp. 1–17.

4. D. Moon et al., “Implementation of the USB Token System for Fingerprint Verification,” Proc. 13th Scandi-navian Conf. (SCIA 03), LNCS 2749, Springer, 2003, pp. 998–1005.

5. Y. Lin, X. Maozhi, and Z. Zhiming, “Digital Signa-ture Systems Based on Smart Card and Fingerprint Fea-ture,” J. Systems Eng. and Electronics, vol. 18, no. 4, 2007, pp. 825–834.

6. “Smartcards Use Biometrics,” Biometric Technology To-day, vol. 10, no. 5, 2002, pp. 9–11.

7. S. Drimer and S.J. Murdoch, “Keep Your Enemies Close: Distance Bounding against Smartcard Relay Attacks,” Proc. Usenix Security Symp., Usenix Assoc., Sept. 2007.

8. C. Adams and S. Farrell, Internet X.509 Public-Key In-frastructure Certificate Management Protocols, IETF RFC 2510, 1999; www.ietf.org/rfc/rfc2510.txt.

9. C. Lee et al., “Preprocessing of a Fingerprint Image Captured with a Mobile Camera,” Proc. Int’l Conf. Ad-vances in Biometrics (ICB 06), LNCS 3832, Springer, 2006, pp. 348–355.

10. D. Searls and J. Thompson, “The Ultimate Linux Handheld,” Linux J., vol. 148, 2006, pp. 70–71.

11. J. Fierrez et al., “BiosecurID: A Multimodal Biomet-ric Database,” Pattern Analysis & Applications, in press, Springer; DOI: 10.1007/s10044-009-0151-4.

12. J. Viega, M. Messier, and P. Chandra, Network Security with OpenSSL, O’Reilly, 2002.

13. C.L. Wilson, C.I. Watson, and E.G. Paek, “Effect of Resolution and Image Quality on Combined Optical and Neural Network Fingerprint Matching,” Pattern Recognition, vol. 33, no. 2, 2000, pp. 317–331.

14. D. Baldisserra et al., “Fake Fingerprint Detection by Odor Analysis,” Proc. IARP Int’l Conf. Biometrics (ICB 06), LNCS 2832, Springer, 2006, pp. 265–272.

Ricardo Ribalda has been working under a grant from the

Spanish Ministry of Education since 2007 as a PhD candidate

at the Universidad Autónoma de Madrid. His research interests

include operating systems, security, and software and hard-

ware embedded-system applications. Ribalda has an MSc in

computer science engineering from the Universidad Autónoma

de Madrid. Contact him at [email protected].

Guillermo González de Rivera is an assistant professor at

the Universidad Autónoma de Madrid. His research interests

include digital control, robotics, low-power designs, field-

programmable gate arrays, and mobile nodes in wireless sen-

sor networks. de Rivera has an MSc in telecom engineering

from the Universidad Politécnica de Madrid. Contact him at

[email protected].

Ángel de Castro is an assistant professor at the Universidad

Autónoma de Madrid. His research interests include digital

control of switching-mode power supplies, field-programma-

ble gate arrays, and mobile nodes in wireless sensor networks.

de Castro has a PhD in electrical engineering from Universi-

dad Politécnica de Madrid. He’s a member of IEEE. Contact

him at [email protected].

Javier Garrido is a professor of computer science at Univer-

sidad Autónoma de Madrid. His current research interests

include embedded-system applications, field-programmable

gate arrays, and mobile nodes in wireless sensor networks.

Garrido has a PhD in physics from Universidad Autónoma

de Madrid. He’s a member of IEEE. Contact him at javier.

[email protected].

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

2 Free Sample Issues!A $26 value

The magazine of computational tools and methods for 21st century science.

http://cise.aip.org www.computer.org/cise

Send an e-mail to [email protected] to receive the two most recent issues of CiSE. (Please include your mailing address.)

Recent Peer-Reviewed Topics:

Cloud ComputingComputational AstrophysicsComputational NanoscienceComputational Engineering

Geographical Information SystemsNew Directions

Petascale ComputingReproducible Research

Software Engineering

MEMBERS $47/yearfor print & online


A Mobile Biometric System-On-Token System for Signing Digital Transactions

Documents

Transcript of A Mobile Biometric System-On-Token System for Signing Digital Transactions