MARCH/APRIL 2007

VOLUME 5, NUMBER 2

BUILDING CONFIDENCE IN A NETWORKED WORLD

Features
Malware

15 Guest Editor’s Introduction

IVÁN ARCE

17 Studying Bluetooth Malware

Propagation: The BlueBag Project
LUCA CARETTONI, CLAUDIO MERLONI, AND STEFANO ZANERO

Bluetooth worms currently pose relatively little

danger compared to Internet scanning worms.
The BlueBag project shows targeted attacks
through Bluetooth malware using proof-of-
concept codes and mobile devices. COVER ARTWORK BY GIACOMO MARCHESI, WWW.GIACOMOMARCHESI.COM

26 Alien vs. Quine

VANESSA GRATZER AND DAVID NACCACHE
identification of malware. Entropy analysis
enables analysts to quickly and efficiently
identify packed and encrypted samples.
Is it possible to prove a computer is malware-free
without pulling out its hard disk? The authors
introduce a hardware inspection technique based
46 Code Normalization
for Self-Mutating Malware
on the injection of carefully crafted code and the DANILO BRUSCHI, LORENZO MARTIGNONI, AND MATTIA MONGA
analysis of its output and execution time.
Next-generation malware will adopt self-mutation

32 Toward Automated Dynamic

Malware Analysis Using CWSandbox
to circumvent current detection techniques. The
authors’ strategy reduces different instances of the
CARSTEN WILLEMS, THORSTEN HOLZ , AND FELIX FREILING same malware into a common form that can
enable accurate detection.
The authors present CWSandbox, which
executes malware samples in a simulated Identity Management
environment, monitors all system calls, and
automatically generates a detailed report to
simplify the malware analyst’s task.
55 Trust Negotiation in Identity Management
ABHILASHA BHARGAV-SPANTZEL, ANNA C. SQUICCIARINI,
AND ELISA BERTINO

40 Using Entropy Analysis

to Find Encrypted and Packed Malware
Most organizations require the verification of
personal information before providing services;
ROBERT LYDA AND JAMES HAMROCK the privacy of such information is of growing
In statically analyzing large sample collections, concern. The authors show how federal IdM
packed and encrypted malware pose a systems can better protect users’ information
significant challenge to automating the when integrated with trust negotiation.

Postmaster: Send undelivered copies and address changes to IEEE Security & Privacy, Circulation Dept., PO Box 3014, Los Alamitos, CA 90720-1314. Periodicals postage rate paid at New York, NY, and at additional mailing offices. Canadian
GST #125634188. Canada Post Publications Mail Agreement Number 40013885. Return undeliverable Canadian addresses to PO Box 122, Niagara Falls, ON L2E 6S8. Printed in the USA.
Circulation: IEEE Security & Privacy (ISSN 1540-7993) is published bimonthly by the IEEE Computer Society. IEEE Headquarters, Three Park Ave., 17th Floor, New York, NY 10016-5997; IEEE Computer Society Publications Office, 10662 Los
Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1314, phone +1 714 821 8380; IEEE Computer Society Headquarters, 1730 Massachusetts Ave. NW, Washington, DC 20036-1903. Subscription rates: IEEE Computer Society members
get the lowest rates and choice of media option—$24/29/29 US print + online/sister society/individual nonmember. Go to www.computer.org/subscribe to order and for more information on other subscription prices. Nonmember rate:
available on request. Back issues: $25 for members and $98 for nonmembers.
Copyright and reprint permissions: Abstracting is permitted with credit to the source. Libraries are permitted to photocopy beyond the limits of US copyright law for the private use of patrons 1) those post-1977 articles that carry
a code at the bottom of the first page, provided the per-copy fee indicated in the code is paid through the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923; and 2) pre-1978 articles without fee. For other copying,
reprint, or republication permissions, write to the Copyright and Permissions Department, IEEE Service Center, 445 Hoes Lane, Piscataway, NJ 08855-1331. Copyright © 2007 The Institute of Electrical and Electronics Engineers, Inc. All rights reserved.
 Departments
From the Editors
4 Trusted Computing in Context
FRED B. SCHNEIDER

News
7 News Briefs
BRANDI ORTEGA

Interview
11 Silver Bullet Talks
with Dorothy Denning
GARY MCGRAW

Education SECURE SYSTEMS, P. 80

64 Common Body of Knowledge

Crypto Corner
for Information Security
MARIANTHI THEOHARIDOU AND DIMITRIS GRITZALIS
76 When Cryptographers Turn Lead into Gold
On the Horizon PATRICK P. TSANG

Secure Systems
68 Secure Communication
without Encryption?
KEYE MARTIN
80 A Case (Study) For Usability
in Secure Email Communication
Privacy Interests APU KAPADIA

Digital Protection
72 Setting Boundaries at Borders:
Reconciling Laptop Searches and Privacy
E. MICHAEL POWER, JONATHAN GILHEN,
85 South Korea’s Way to the Future
MICHAEL LESK
AND ROLAND L. TROPE

Building Security In
88 A Metrics Framework to Drive
Application Security Improvement
ELIZABETH A. NICHOLS AND GUNNAR PETERSON

Emerging Standards
92 Infrastructure Standards
for Smart ID Card Deployment
RAMASWAMY CHANDRAMOULI AND PHILIP LEE

84 Ad Product Index

PRIVACY INTERESTS, P. 72 Printed on 100% recycled paper

For more information on these or any other computing topics, please visit the IEEE Computer Society’s Digital Library at http://computer.org/publications/dlib.
 North Atlantic Treaty Organisation

Call for proposals on

Information and Communications Security

The North Atlantic Treaty Organisation’s Science for Peace and Security programme invites
scientists working in the field of Information and Communications Security to apply for fi-
nancial support to support their research effort.

nato wishes to foster research in all fields related to information and communications
security. This includes, but is not limited to, the following topics:
◆ Security-related aspects of information systems and networks, such as
Information security: identification and authorization, cryptography,
privacy and data protection, back-up and physical protection
 Encouraging security awareness: security workshops, risk assessment and
management, security policies and standards
 Infrastructure security and reliability: physical and organizational protection
and resources, security tools and network services, establishing the
infrastructure for a Computer Emergency Response Team (CERT)
 Cyber-crime and terrorism
◆ Computer networking
◆ E-learning
◆ Development of virtual communities, development of educational internet content
and software

nato Science for Peace and Security grants may take several forms:
◆ Networking infrastructure grants
◆ Advanced research workshops, advanced networking workshops, advanced study
institutes
◆ Collaborative linkage grants
◆ Applied R&D projects
◆ Reintegration grants

Information on the Science for Peace and Security programme including

deadlines, conditions for eligibility, and application forms are available online at
http://www.nato.int/science/. Further enquiries should be directed to science@hq.nato.int.
 From the Editors

Trusted Computing
in Context

M
uch has been said about what makes cyber- all, but then I become skeptical that
a secure cyberspace could be built
space insecure and who’s at fault. Software from components that would be
available.
producers are often singled out as a source The right of computer owners
to control what their computers
of remedy. Actions these producers take in execute is seen as sacrosanct by crit-
ics of trusted computing. I don’t
the name of improving the security of cyberspace, however, are think it’s that simple, and I see
analogies with other rights and re-
sometimes viewed with suspicion. avoided! Perhaps system designers sponsibilities of individuals in a so-
The so-called trusted computing could discharge the responsibility ciety. For example, we all benefit
technology embodied in the of securing cyberspace in some from the cleaner environment that
Trusted Platform Module (TPM) other way. Nobody has yet devised comes from limiting how individu-
secure-coprocessor from the Trust- such a way, but one might exist; it als use property they own. Imping-
ed Computing Group (www.trusted would not only involve eliminating ing on the rights of individuals here
computinggroup.org) is a case in vulnerabilities but also preventing produces benefits for all. And, we
FRED B. point. Here, a hardware-based root human users from being spoofed all benefit from vaccinating every-
SCHNEIDER of trust makes it possible for the sys- into unwittingly aiding attackers. one against a disease, even if it in-
Associate tem designer—not the computer Or perhaps system designers volves relinquishing some control
Editor in Chief owner—to regulate which pro- shouldn’t feel any responsibility at over our bodies (and carries some
grams can run on a given computer.
If system designers are evil, then
they can use trusted computing to
prevent a competitors’ programs Letters to the Editor
from being installed, thus creating
or preserving a monopoly. When Dear Editors, software.” I hope that you have the
computer owners are incompetent, I’d like to thank Gary McGraw for chance to make him a guest on an
though, benevolent system design- the time and effort put into the upcoming show!
ers can use trusted computing to Silver Bullet Security Podcast and Once again, thank you very
prevent malware from being in- articles. They’re very enjoyable and much!
stalled (perhaps unwittingly) and bring a lot of broadening per-
run. Unlike most defenses, which spectives to any security practi- Best regards,
the system operator controls, tioner. One person that I personally Robert Malmgren
trusted computing provides a way to think is missing from that long line Information security professional
save naïve or incompetent com- of interesting persons that you’ve
puter owners from themselves. interviewed is Ross Anderson Gary McGraw responds:
Most computer owners aren’t com- (www.cl.cam.ac.uk/~rja14/) and Great idea. Ross is an old friend
puter scientists, and thus need this his ideas on security engineering. and would be an excellent victim.
help. (Many computer scientists All the work he and others have At your suggestion, I arranged for
need this help, too.) done lately in trying to marry an upcoming interview with him
Trusted computing introduces a together economical science and that will appear in mid-April. By
tension between the rights of com- computer science / IT security is an now you have heard the Becky
puter owners and the (presumed) interesting way to try to describe Bace interview posted in March,
responsibilities of system designers. why we have this “sorry state of right?
Would that this tension could be

4 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY

risk of side-effects) because the
chances are reduced of the unvacci-
nated contracting the disease (herd
immunity) and the costs are re-
duced for care and lost productivity
when someone does. In short, there
is a precedent and a tradition of re-
linquishing individual rights for the
greater good.
In cyberspace, insecure ma-
chines can be attacked and co-
opted to serve in armies of zombies,
which then cause annoyance by
sending spam or wreak havoc by
participating in distributed denial-
of-service attacks. All of us in cy-
berspace are put at risk when
someone else’s computer has been
co-opted. The rights of computer
owners to control what their com-
puters execute thus comes with a
responsibility—the responsibility
not to execute malware that might
pollute or infect other parts of cy-
berspace. Trusted computing helps
to discharge that responsibility by
transferring decision making to a
presumably knowledgeable system
designer from a likely naïve com-
puter owner.
T rusted computing might not
embody the best trade-off, but it
does represent a plausible option in a
world where you can’t depend on
everyone who operates a computer
to do the right thing. In particular,
trusted computing makes it possible
to educate and depend on relatively
few software producers instead of
the ever growing number of
computer owner-operators, an ar-
gument about leverage—not tech-
nology. Overall, there has been
disappointingly little discussion in
the computer security community
about assignments of rights and re-
sponsibilities. Much could be
gained from formulating and evalu-
ating security solutions in such
terms, making assignments of rights
and responsibilities in a way that best
leverages the diverse capabilities of
participating communities.
From the Editors
www.ini.cmu.edu
Carnegie Mellon University
4616 Henry Street
Pittsburgh, PA 15213
USA
Call for Faculty
The Information Networking Institute (INI) at Carnegie Mellon University is
soliciting applications for one Systems Scientist faculty position in the areas of
networking, computer systems and security, to begin Fall 2007. The position is
based in Pittsburgh, PA but will also include travel associated with INI’s international
graduate programs. Responsibilities include teaching core technical courses for
the Master of Science in Information Technology - Information Security track
(MSIT-IS) and Master of Science in Information Networking (MSIN) programs,
advising graduate students, as well as participating in research projects related
to the initiatives of Carnegie Mellon CyLab.
Candidate must demonstrate a strong commitment to teaching and a proven
research track record in the areas of networking, computer systems and/or
security. Industrial working experiences in information technology or management
are particularly welcome. A Ph.D. in Computer Science, Electrical Engineering,
or closely related field is required.
Submit curriculum vitae, publication list, and other supporting documentation to:
Dena Haritos Tsamitis
Director, Information Networking Institute
email: denat@ece.cmu.edu
Silver Bullet Sponsored by
Security Podcast series
and
Check out the Silver Bullet Security Podcast with host Gary McGraw,
author of Software Security, Exploiting Software, and Building
Secure Software! This free series features in-depth interviews with
security gurus, including
• Avi Rubin of Johns Hopkins
• Marcus Ranum of Tenable Security
• Mike Howard of Microsoft, and
• Bruce Schneier of Counterpane Internet Security
Stream it online or download to your iPod...
www.computer.org/security/podcasts
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 5

EDITOR IN CHIEF
Carl E. Landwehr • University of Maryland • landwehr@isr.umd.edu
ASSOCIATE EDITORS IN CHIEF
Marc Donner • Google • donner@tinho.net
Fred B. Schneider • Cornell University • fbs@cs.cornell.edu
EDITORIAL BOARD
Martin Abadi, University of California, Santa Cruz
Elisa Bertino, Purdue University
Michael A. Caloyannides, Ideal Innovations
George Cybenko, Dartmouth College (EIC Emeritus)
Dorothy E. Denning, Naval Postgraduate School
Anup K. Ghosh, George Mason University
Dieter Gollmann, Technical University Hamburg-Harburg
Guofei Jiang, NEC Research Labs, Princeton
David Ladd, Microsoft Research
Tom Longstaff, Carnegie Mellon Univ., CERT/CC
Nasir Memon, Polytechnic University
Peter Neumann, SRI Int’l
Avi Rubin, Johns Hopkins University
Sal Stolfo, Columbia University
Giovanni Vigna, University of California, Santa Barbara
DEPARTMENT EDITORS
Attack Trends: Iván Arce, Core Security Technologies
Basic Training: Richard Ford, Florida Institute of Technology;
and Michael Howard, Microsoft
Book Reviews: Charles P. Pfleeger, Pfleeger Consulting Group;
Shari Lawrence Pfleeger, RAND;
and Martin R. Stytz, Institute for Defense Analyses
Building Security In: John Steven, Cigital;
and Gunnar Peterson, Arctec Group
Conference Reports: Carl E. Landwehr, University of Maryland
Crypto Corner: Peter Gutmann, University of Auckland;
David Naccache, École normale supérieure;
and Charles C. Palmer, IBM
Digital Protection: Michael Lesk, Rutgers University; Martin R. Stytz;
and Roland L. Trope, Trope and Schramm
CS MAGAZINE OPERATIONS COMMITTEE
Robert E. Filman (chair), David Albonesi, Jean Bacon, Arnold (Jay)
Bragg, Carl Chang, Kwang-Ting (Tim) Cheng, Norman Chonacky,
Fred Douglis, Hakan Erdogmus, David A. Grier, James Hendler,
Carl Landwehr, Sethuraman (Panch) Panchanathan, Maureen
Stone, Roy Want
CS PUBLICATIONS BOARD
Jon Rokne (chair), Mike Blaha, Angela Burgess, Doris Carver, Mark
Christensen, David Ebert, Frank Ferrante, Phil Laplante, Dick Price,
Don Shafer, Linda Shafer, Steve Tanimoto, Wenping Wang
Editorial: Unless otherwise stated, bylined articles as well as products
and services reflect the author’s or firm’s opinion; inclusion does
not necessarily constitute endorsement by the IEEE Computer
Society or the IEEE.
BUILDING CONFIDENCE IN A NETWORKED WORLD
Education: Matt Bishop, University of California, Davis;
and Deborah A. Frincke, Pacific Northwest National Laboratory
Emerging Standards: Ramaswamy Chandramouli, NIST;
Rick Kuhn, NIST; and Susan Landau, Sun Microsystems Labs
Interview: Gary McGraw, Cigital
On the Horizon: O. Sami Saydjari, Cyber Defense Agency
Privacy Interests: E. Michael Power, Gowling Lafleur Henderson;
and Roland L. Trope
Secure Systems: Sean W. Smith, Dartmouth College
COLUMNISTS
Clear Text: Bruce Schneier, Counterpane Internet Security;
Steve Bellovin, Columbia University; and Daniel E. Geer Jr., Verdasys
STAFF
Lead Editor: Kathy Clark-Fisher, kclark-fisher@computer.org
Group Managing Editor: Steve Woods
Staff Editors: Rebecca L. Deuel, Jenny Stout, and Brandi Ortega
Production Editor: Monette Velasco
Magazine Assistant: Hazel Kosky, security@computer.org
Contributing Editors: Keri Schreiner and Joan Taylor
Original Illustrations: Robert Stack
Graphic Design: Alex Torres
Publisher: Angela Burgess, aburgess@computer.org
Associate Publisher: Dick Price
Membership & Circulation Marketing Manager: Georgann Carter
Business Development Manager: Sandra Brown
Assistant Advertising Coordinator: Marian Anderson,
manderson@computer.org
Submissions: We welcome submissions about security and privacy
topics. For detailed instructions, see the author guidelines at
www.computer.org/security/author.htm or log onto S&P’s author
center at Manuscript Central (www.computer.org/mc/security/
author.htm).
Editorial Office:
IEEE Security & Privacy
c/o IEEE Computer Society Publications Office
10662 Los Vaqueros Circle
Los Alamitos, CA 90720 USA
Phone: +1 714-821-8380
Fax: +1 714-821-4010
www.computer.org/security/

NewsBriefs
Security
■ According to Karl Lynn of Juniper Networks, older
versions of Citrix’s Presentation Server Client contain a
security flaw that could compromise machines. The
flaw is a result of an error in Citrix’s proprietary inde-
pendent computing architecture (ICA) protocol and the
way it supports connections via proxy servers, possibly
letting attackers execute arbitrary code when users visit
malicious Web sites. The flaw affects Presentation Server
Client versions older than 10.0. Currently, no patch is
available; as a fix, Citrix recommends users upgrade to
version 10.0.
■ At the recent Black Hat DC conference in February, David
Litchfield revealed a technique dubbed cursor injection to
exploit PL/SQL injection vulnerabilities in Oracle
database servers. Previous attacks using PL/SQL flaws
required high-level database privileges, but cursor injection
lets anyone who can connect to a database exploit the flaws.
In response, Oracle urged customers to apply patches.
■ IOActive, a security firm based in Seattle, Washington,
cancelled its scheduled demonstration of the flaws in RFID-
enabled access badges at the Black Hat DC conference. The
company decided not to go ahead with its presentation after
receiving legal threats from HID Global, a major manufacturer
of RFID access control systems. IOActive’s chief executive,
Joshua Pennell said, “We can’t go forward with the threat
hanging over our small company.” In a statement, HID Global
said it didn’t threaten IOActive, but “simply informed IOActive
and its management of the patents that currently protect HID
Global intellectual property.”
■ In February 2007, Microsoft warned of an Excel 0-day
attack that affects Office 2000, 2004, XP, and Office
2004 for Mac. The attack exploits a vulnerability that lets
attackers remotely take over users’ systems after they’ve
opened a malicious Excel attachment or visit a Web site that
houses the malicious files. No patch is yet available, but
Microsoft advises users not to open MS Office files from
unknown sources.
■ According to researchers at Harvard and MIT, site-
authentication images used by financial institutions such
as Bank of America, ING Direct, and Vanguard provide little
additional security. Customers preselect an image that will
appear to them when they access their accounts online; if
PUBLISHED BY THE IEEE COMPUTER SOCIETY
Editor: David Ladd, daveladd@microsoft.com
they don’t see the image, they could be at a phishing site
and shouldn’t enter a password. In a controlled computing
environment, the researchers removed the images, and
tested 67 Bank of America customers by asking them to log
into their online accounts. Of the participants, 58 entered
their passwords; only two chose not to because of security
concerns. Those who entered their passwords said they
didn’t notice their images weren’t present.
■ To combat phishing, Microsoft added support for
Extended Validation Secure Sockets Layer (EV SSL) cer-
tificates to Internet Explorer 7.0 and urges other browser
makers and Web sites to follow. EV SSL-certified Web sites
feature an address bar that turns green, displays the country
the Web site is based in, and who certified it. EV SSL-
certification guidelines also require third-party authenti-
cation companies, such as VeriSign and Entrust, to verify
that they have registered with local authorities, have a
legitimate address, and actually control the site. VeriSign
says 300 businesses are in the process of certification, and
that it has issued 20 EV SSL certificates so far.
■ In January 2007, Exploit Prevention Labs, an Atlanta-
based security company, reported that the Q406 roll-up
attack kit was behind 70 percent of the Web-based
attacks in December 2006. Exploit’s chief technology
officer, Roger Thompson, says it’s hard to pinpoint the kit’s
exact number of exploits because it’s heavily encrypted.
“The dominance of this package reinforces the fact that the
development and release of exploits frequently parallels
legitimate software businesses,” Thompson says.
■ Recently, Symantec released new security software to
help combat 0-day attacks. The new tool—Symantec
Online Network for Advanced Response (SONAR)—is a
free add-on to Norton Antivirus 2007 and Internet Security
2007 products. SONAR differs from Symantec’s signature-
based antivirus tools in that it’s behavior-based: it analyzes
program behavior to determine whether malicious activity
is occurring, thus identifying suspicious behavior before
security researchers.
■ To help protect against phishing scams, eBay now offers
password-generating devices to its PayPal users. The device,
dubbed the PayPal Security Key, generates random six-
digit security codes every 30 seconds and costs personal
PayPal account users a one-time fee of US$5, but is free for
business accounts. PayPal users enter the unique six-digit
■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY 7
 NewsBriefs
code when they log in to their accounts with their regular
user names and passwords. The code then expires. The
service is available to PayPal users in the US, Germany, and
Australia, but the company will eventually extend the service
to other countries as well.
■ In response to recent attacks on the SHA-1 hash function, the US National
Institute of Standards and Technology (NIST) is holding a public competition
to develop a more secure hash algorithm. NIST has published a draft on sub-
mission requirements and evaluation criteria and is currently accepting public
comments on the draft. The submission deadline for new hash functions is ten-
tatively scheduled for the third quarter of 2008. More information is available at
www.csrc.nist.gov/pki/HashWorkshop/index.html.
■ To fight against terrorism, Pakistan installed a bio-
metrics system at the main border crossing between its
southwestern Baluchistan province and southern
Afghanistan in January 2007. The system records finger-
prints, retinas, or facial patterns and matches them to bio-
metrically enabled Pakistani passports or identity cards.
■ Cambridge University researchers revealed a proof-of-
concept hack to the UK’s Pin-and-Chip system’s
hardware that could let attackers steal personal data. The
researchers replaced a terminal’s internal hardware with
their own and got it to play Tetris. The demonstration
showed that attackers could make all of a terminal’s com-
ponents interact with one another, leading to the capture
of data such as PINs.
■ A phishing toolkit available on underground forums
is threatening to bring cybercrime to the masses with an
easy-to-use interface that requires minimal, if any, pro-
gramming skill. Using the toolkit, which sells for US$1,000,
scammers only need to enter a few variables, such as the
Web site to be spoofed and the host site for the phony page,
and the tool does the rest: it uses PHP to produce a dynamic
Web page that pulls in the actual Web site being phished
and displays it to unsuspecting users. Users logging into
the legitimate site never know that scammers are inter-
cepting their data.
■ The US Department of Homeland Security is planning
Cyber Storm 2, a weeklong exercise slated for March
2008 to test the nation’s response to a full-scale cyber-
attack. Cyber Storm 1 occurred in March 2006, with 115
private and international companies and organizations par-
ticipating, and included a physical and Internet-based attack
on private and public-sector companies.
■ Satellite navigation company TomTom reported that
its TomTom GO 910 units manufactured between
September and November 2006 might be infected with
viruses. The personal car navigation devices include a 20-
Gbyte hard drive and preloaded maps of the US, Canada,
8 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
and Europe. The company recommends that users run
antivirus programs and remove the infected files.
Privacy
■ In February 2007, the US Veterans Administration
reported an external hard drive missing from an
employee’s computer that contained information on
almost all US physicians who have billed Medicaid and
Medicare along with medical data for roughly 535,000
VA patients.
■ US Congressman Lamar Smith (R-Tex.) has
introduced the Stopping Adults from Exploiting Today’s
Youth (SAFETY) Act of 2006, which would let the US
Attorney General draft far-reaching data retention laws
for ISPs. Privacy advocates cite the act’s vagueness as a
major concern. “This bill is so incredibly bad…there’s
nothing in this legislation to prevent the attorney general
from simply saying, ‘Save everything forever,’” said Lauren
Weinstein from the People for Internet Responsibility, an
advocacy group. Smith counters that the act’s focus is on
catching sexual predators and that a subpoena would be
required to access the information.
■ Smart Card Alliance, which includes charter members
IBM, First Data, Visa, and Northrop Grumman, released
guidelines in February 2007 for best practices in security
and privacy for companies using RFID technology in
identity-management systems. The guidelines range from
implementing security techniques such as mutual authenti-
cation to privacy practices such as allowing users to correct
information and instituting a dispute-resolution process.
■ IBM donated its Identity Mixer—software that provides
encrypted credentials for online transactions—to the
Higgins project, an open source project that give users
more control over their personal data by making multiple
authentication systems work together. Identity Mixer lets a
trusted authority, such as a bank or government agency,
issue an encrypted credential that users would give instead
of personal or credit information while online. Buyers, for
example, would give the encrypted credential to online
stores, which would pass it to the credit-card issuer, who
decrypts it, verifies it, and pays the retailer. A first version of
the Higgins project, with the Identity Mixer software, is
slated for release in mid-2007.
■ A judge with the US Foreign Intelligence Surveillance Act
(FISA) court authorized US President George W. Bush’s
controversial wiretap program, giving the program
court oversight after five years, a move that critics say
makes it unconstitutional. The program—called the Terrorist
Surveillance Program—lets the government wiretap phone
and Internet communications—without warrants—into and

out of the country when the caller or receiver has a sus-
pected link to Al Queda. The program will continue with
court oversight and move out from under the US National
Security Agency’s purview.
■ In January 2007, the parent company of retailers T.J.
Maxx, Marshalls, HomeGoods, and A.J. Wright stores
announced that the computer network it uses to handle
credit- and debit-card transaction was breached in mid-
December. The breach affected stores throughout the US
and Puerto Rico, as well as Winners and HomeSense stores
in Canada. According to the New Hampshire Bankers
Association (NHBA), roughly 20 to 30 percent of all New
Englanders might have been affected by the breach.
■ Senetas, an Australian cryptography company, and id
Quantique SA, a quantum cryptography company based in
Geneva, have created a 1- to 10-Gbit network that
combines quantum key distribution with traditional
encryption techniques. Quantum cryptography uses photon
polarization to represent 1s and 0s instead of encryption keys
to scramble data, producing uncrackable codes. The com-
panies plan to offer the first networks in mid-2007.
■ The UK’s Information Commissioner’s Office (ICO)
warned that the government’s new recommendation
to relax data-sharing laws could lead to governmental
snooping. The recommendation came after Prime
Minister Tony Blair held a seminar to review the UK’s
current data-sharing law—the Data Protection Act—and
found that, “overzealous data-sharing rules may be an
obstacle to improving public services.” In a statement, the
ICO said the government must have security and privacy
safeguards in place and take a measured approach so as
to avoid government abuses and erosion of public trust.
“…a cautious approach to information sharing is needed
in order to avoid the dangers of excessive surveillance and
the loss of public trust and confidence,” the statement
said. The recommendation has been put to a public
debate; results will be reported back to the Cabinet in
March 2007 for further review.
■ Microsoft confirmed that it sought assistance—and
received it—from the US National Security Agency (NSA)
in developing Vista’s security configuration. The move
was to ensure that Vista met the US Department of
Defense’s standards, according to NSA spokesman, Ken
White. However, Marc Rotenberg, director of the Electronic
Privacy Information Center (EPIC), says, “There could be
some good reason for concern. Some bells are going to go
off when the government’s spy agency is working with the
private sector’s top developer of operating systems.” White
says the NSA’s role was limited to configuration aspects, not
development, and especially not to system back doors,
which the NSA has shown interest in. “This is not the devel-
NewsBriefs
opment of code here,” White says. “This is the assisting in
the development of a security configuration.”
■ Later this year, MySpace.com will start offering
Zephyr, parental notification software that lets parents
know the name, age, and location their children use while
on the social network. The software, however, doesn’t let
parents read their children’s email or see their profiles.
Privacy concerns, including whether the software could be
used to monitor other users, prompted Facebook and
blogging site Xanga to decline use of the software.
■ In February 2007, Wellpoint, the largest US health
insurer and parent company of Anthem Blue Cross and Blue
Shield, reported the theft of backup tapes that contained
196,000 customers’ personal information. The tapes were
stolen from a company that audits the insurer’s claims. The
company sent letters to those affected, all of whom live in
Kentucky, Indiana, Ohio, and Virginia.
■ German police in the state of Sachsen-Anhalt worked
with credit-card companies to review more than 22 million
customers’ transactions in an effort to nab child pornog-
raphers. The operation, called Mikado, netted 322 people
suspected of buying Internet child pornography. Under
German law, the police can require financial institutions to
provide customers’ transaction data if the police provide
very explicit search criteria. In this instance, the police
narrowed their requests down to a specific amount of
money, time period, and receiver account.
■ Vermont’s Agency of Human Services (AHS) reported
a computer breach affecting roughly 70,000 state res-
idents that might have exposed personal information,
including social security numbers. Heidi Tringe, the state’s
communications director, said the breach appeared to be
■ Swedish police believe that a Russian organized crime gang used a variant
of the Haxdoor Trojan to bilk US$1.1 million dollars from a Swedish online
banking site. The criminal gang targeted Nordea customers with phishing emails
that urged them to download a “spam fighting” application that was in fact the
Haxdoor Trojan. The Trojan payload activated when users tried to log into the
bank’s online site and were then redirected to a phony home page, where key-
loggers installed by the Trojan recorded account information. The gang then used
the information to log into the real banking site and drain customer accounts.
Nordea has refunded the affected customers’ money.
the result of a botnet attack. The state sent letters to those
affected by the breach, warning them of the compromise.
Policy
■ In February 2007, the European Union (EU) officially
launched the Consumer Protection Cooperation (CPC)
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 9
 NewsBriefs
Network, a consumer-protection network that’s designed
to aid law enforcement in tracking down perpetrators of
cross-border fraudulent activity, including spam and
phishing scams. The CPC Network was instituted under the
Consumer Protection Cooperation Regulations, which EU
countries passed in 2004. The CPC Regulations set the
minimum compliance standards for enforcement authorities
■ US President George W. Bush signed the Telephone Records and Privacy
Protection Act of 2006, making telephone pretexting—impersonating someone
else for the purpose of buying, selling, or obtaining personal phone records—a
federal crime punishable by up to 10 years’ imprisonment. Of course, law
enforcement and intelligence agencies are exempt.
in the network and include enforcement regulations such as
the ability to conduct on-site inspections and order com-
panies to stop illegal practices.
■ The Massachusetts legislature is considering two bills
aimed at curbing retailers’ poor data security practices.
Currently, banks that issue credit or debit cards to consumers
who’ve been victimized by data breaches absorb the costs
to stop the fraudulent activity, with the retailers only on the
hook for free credit-monitoring services. However, the first
bill—HB 213—will make retail companies liable for the costs
incurred as a result of a data breach. Companies involved in
a breach would be required to notify customers and
reimburse the card-issuing banks for subsequent fraudulent
activity, including the costs to cancel or reissue cards as a
result of unauthorized transactions. Also up for consideration
is HB 328, which would require companies to provide credit
freezes to those consumers affected by their data breach.
Both bills aim to encourage retailers to improve data security.
■ Karen Evans, the US Office of Management and Budget’s
administrator for e-government and IT, said in a recent con-
ference call that the federal agencies that don’t protect
personal information might get a smaller portion of
President Bush’s IT budget. “This year we’re really focused
on making sure agencies are delivering results, investing the
taxpayers’ dollars wisely, and are really executing now on
the activities they said they are going to do,” said Evans.
President Bush recommended an overall increase of 2.6
percent for this project for the 2008 fiscal year. The US
Department of Defense (DoD) is slated for the lion’s share
of the budget, with $31.4 billion; the agency with the
second highest budget is the Department of Health and
Human Services, at $5.6 billion. The allocations “represent
the President’s priorities going forward to combating the
war on terror,” Evans said.
■ A new bill sponsored by US Senators Patrick Leahy (D-
Vt.), Russ Feingold (D-Wis.), and John Sununu (R-N.H.),
would require US government agencies to report to
10 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
Congress on their development and use of data mining
programs. Senator Leahy said the bill—the Federal Agency
Data Mining Reporting Act—would provide an “oversight
mechanism” and safeguard privacy. Testifying before
Congress, Leahy said that government agencies are
operating, or planning to operate, roughly 199 data mining
programs, including the controversial Automated Targeting
System, which assigns “terror scores” to US airline pas-
sengers, and the Secure Flight program, which analyzes
airline-passenger data. “The American people have neither
the assurance that these massive data banks will make us
safer nor the confidence that their privacy rights will be
protected,” Leahy testified.
■ Despite the US Government Accountability Office’s
(GAO’s) recommendation to test the program’s security and
technology, the Transportation Security Administration
(TSA) is going ahead with its rollout of smart-card IDs
for all of the more than 750,000 port workers across the
country. Starting in March, the Department of Homeland
Security (DHS) will issue the IDs, which will contain port
workers’ photographs and fingerprints, after conducting
criminal background checks on all workers. In a report pub-
lished in October 2006, GAO auditors expressed concern
over the TSA’s limited testing scope and that it failed to
gather data on the “operational effectiveness” of the smart-
card readers in maritime conditions, given that the nation’s
4,000 ports tend to be near water.
■ In January 2007, MI5, Britain’s domestic spy agency,
began a new email service that alerts the public about
security threat levels. To receive the email alerts, users
must sign up and register on the MI5 Web site. The move
is part of the agency’s efforts to emerge from its decades-
long policy of secrecy. “It’s part of the service’s ongoing
effort to improve its public communications and contribute
to the government’s policy of keeping the public informed
about the national threat level,” says a spokesperson for
the UK’s Home Office.
■ In February 2007, US Senators Patrick Leahy (D-Vt.) and
Arlen Specter (R-Pa.) revived a similar version of their 2005
Personal Data Privacy Act. This new bill would impose
fines and prison time for those who intentionally conceal
information on data breaches that cause “economic
damage to one or more persons.” Additionally, the bill
would require data brokers to let consumers view and
correct information about themselves for a “reasonable fee.”
■ The UK plans to close 551 of its 951 government Web
sites and fold the services they offered into its DirectGov or
BusinessLink Web sites. Of the remaining 400 sites, 26 will
stay; the fate of the remaining 374 will be decided by June
2007. The goal is to expand information sharing between
departments and consolidate services.

Interview
Silver Bullet Talks
with Dorothy Denning
GARY MCG RAW
Cigital
D
orothy Denning is a professor
in the Department of Defense
Analysis at the Naval Post-
graduate School (NPS) in Monterey,
California. Denning has also worked
at the Stanford Research Institute
and Digital Equipment Corporation.
Featured here is an excerpt
adapted from the full interview be-
tween Denning and Silver Bullet
host Gary McGraw. Their conversa-
tion ranged widely, from teaching
computer security to the Big Sur
Power Walk. You can listen to the
podcast in its entirety at www.
computer.org/security/podcasts/ or
www.cigital.com/silverbullet, or you
can subscribe to the series on iTunes.
Gary McGraw: You’ve been in
academia for much of your career,
teaching at Purdue and Georgetown
and now NPS. What’s the best way
to teach computer security?
Dorothy Denning: I don’t know
what the best way is. I honestly don’t.
I can only tell you how I do it, which
is to look at both the attack side and
the defense side and try to make
some sense out of the field and why
we need certain kinds of defenses.
McGraw: Do you think that teach-
ing particular courses on security is
the best way, or is it better to have a
little bit of security in all courses?
PUBLISHED BY THE IEEE COMPUTER SOCIETY
Denning: I think you need to have
courses that are dedicated to security,
particularly topics such as cryptogra-
phy, which would be hard to inte-
grate into another class. The field is
just way too big to squeeze a little bit
here and there into other courses. If
you’ve got a course on computer net-
works, to do justice to the security
part really requires another course.
On the other hand, you do want
to cover some security in courses,
particularly courses on software de-
velopment. Students have to under-
stand why it’s important to check
your input parameters and do vari-
ous other things so that the software
doesn’t end up being shipped with
vulnerabilities.
McGraw: Greg Hoglund and I cited
your book, Information Warfare and
Security [Addison-Wesley, 1998], on
page five of our book, Exploiting
Software [Addison-Wesley, 2004].
We did that because we wanted peo-
ple to understand that the things we
were talking about in that book
could in fact be applied during
wartime. What role does describing
and understanding real attacks play
in computer security?
Denning: You need to understand
how attacks work because you need
to understand how IP spoofing
works, what happens during denial-
of-service attacks, and how packets
get past firewalls, and so on. How
can you build a firewall if you don’t
■ 1540-7993/07/$25.00 © 2007 IEEE
Editor: Gary McGraw, gem@cigital.com
understand what the threats are
against that firewall?
McGraw: Some people claim that
we should only let specialists have
that knowledge because it’s too dan-
gerous and that it shouldn’t be writ-
ten, published, or talked about.
What’s your position?
Denning: Again, I don’t think you
can do good defense without un-
derstanding offense. I don’t see how
you can teach defense without
teaching offense. If you’re talking
about how you want to do authenti-
cation, you’ve got to understand
what the threats to password files are
and how they’re cracked and sniffed
off of networks.
McGraw: I think sometimes people
believe, for whatever reason, that if
you just talk about building defect-
free software or how cryptography
works or security functionality that
you can ignore the attack part be-
cause it would become irrelevant. I
don’t think that’s really true.
Denning: Right, because the whole
field is evolving. There’s constantly
new attack methods and they’re
outside of the models that we design
our security around. You’re con-
stantly having to invent new de-
fenses to go with the new attacks.
Then new software is rolling out
continuously, which people find
vulnerabilities in, so you’re getting
■ IEEE SECURITY & PRIVACY 11
 Interview

taking off now as an important con-

About Dorothy Denning cept in computing and networking.
To the extent that information will
be encrypted based on location, or
D orothy E. Denning is a professor in the Naval Postgraduate School’s
Department of Defense Analysis. She previously taught at Georgetown
University, where she was the Callahan Family Professor of Computer
that people will be authenticated
based on their geographical loca-
Science and Director of the Georgetown Institute of Information Assurance, tion—I don’t know to what extent
and Purdue University. those might become more prevalent.
She has published 120 articles and four books, including Information
Warfare and Security (Addison-Wesley Professional, 1998). She is an ACM McGraw: One of the trade-offs—
Fellow and recipient of several awards, including the Augusta Ada Lovelace and there are always trade-offs in-
Award and the National Computer Systems Security Award. In November 2001, Time magazine volved in security—is that it could be
named her to its innovators list. Her past leadership positions include president of the dangerous to broadcast your location.
International Association for Cryptologic Research and chair of the National Research Council
Forum on Rights and Responsibilities of Participants in Network Communities. Denning: You wouldn’t have to
Denning has a PhD in computer science from Purdue University. Her research interests include broadcast your location. That com-
terrorism and crime, conflict and cyberspace, information warfare and security, and cryptography. munication could go encrypted.

McGraw: And then come to you

more new attacks and you need
more defenses. The two are cou-
pled. It’s like the front and back of
your hand. You can’t talk about one
without talking about the other.
McGraw: Possibly one of the biggest
controversies you’ve been involved
in professionally was the whole Clip-
per chip dustup [the Clinton admin-
istration’s 1993 encryption proposal,
which used a US National Security
Agency-created computer chip that
provided a government backdoor to
encrypted files using escrowed keys,
for which Denning was an advocate].
What was it like being dubbed the
“Clipper chick”?
Denning: Actually, it was a friend of
mine who gave me that name.
McGraw: Well, it certainly got
picked up and flung around. What
was it like being in the middle of that
controversy?
Denning: It was really rough. I felt
like it damaged a lot of my relation-
ships with people in the field.
McGraw: Did you think that to
some extent some of the arguments
were caricaturing things or making
them ridiculously simple to make a
political point?
Denning: Yes, there was a lot of that
going on. The hardest part for me was
the ad hominem attacks. From my
perspective, I just wanted people to
have a rational debate on the topic but
that didn’t happen. I was rarely in a set-
ting where it looked like that. It was
such an emotionally charged issue.
McGraw: Switching gears, you’re
widely regarded as the inventor of
geoencryption. Do you think that
this spatial concept will escape the
defense community and move into
areas such as geographic marketing?
Denning: Geoencryption, first of
all, really wasn’t my idea. Even loca-
tion-based security wasn’t my idea. I
originally got involved because Pete
MacDoran had a company and he
was doing location-based authenti-
cation. He later got involved with
folks who were interested in loca-
tion-based encryption and already
had a concept. So I tried to provide
greater security and methods for
doing it, but I don’t really deserve
credit for the idea.
McGraw: Do you think geoloca-
tion is going to catch on with the
general public with GPS devices
such as those in cell phones and cars?
Denning: Yes. Location is certainly
and only be decrypted if you happen
to be in the right place?
Denning: Right.
McGraw: I suppose a lot of people
aren’t aware of the fact that many of
the gizmos that they carry around
have this geolocation capability built
into them. Do you think that we
should make a point of making peo-
ple more aware of that, or is it just
something that happens and you just
live with it?
Denning: It will probably happen at
the rate that’s needed to understand
what’s happening with the technol-
ogy. I think a lot more people are
aware of it—many people know that
if they’re in an emergency situation,
somebody can find out where they
are through their cell phones.
McGraw: I was talking to some cell
phone vendors and they don’t want
to advertise the fact that you can be
geolocated. Not because people
might be worried about privacy, but
because they’re worried about liabil-
ity in case it doesn’t work. Imagine
that someone kidnaps your kids and
you’re trying to use a cell phone to
geolocate them and it doesn’t work.
Then whose fault is it if it doesn’t
work after the vendors make claims

12 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007


that it does? Strangely, that’s one of
the things that’s holding that kind of
technology back right now.
Denning: That could be.
McGraw: You and I have very similar
opinions about cybercriminals. We
both think that cybercriminals are
bad and that we shouldn’t spend time
hyping these guys up into rock stars.
But your view on that seems to have
evolved pretty radically over the years.
What changed your mind? Did it
happen all at once or gradually?
Denning: I don’t think my views
have evolved all that much.
McGraw: Okay. So what is your
view now?
Denning: There’s a lot of bad guys
out there. A lot of them are doing it
for money. It’s just plain old crime.
In my early work, I honestly didn’t
pay too much attention to who the
bad guys were and the methods they
used. I was looking at security from a
totally theoretical perspective. It was
in the late ’80s, around 1990, that I
did a study where I interviewed
some hackers. The hackers I inter-
viewed, about a dozen of them, were
all pretty decent folks, I thought. I
wrote an article about them and I
probably came across as sounding
like they were fairly decent folks, but
without trying to necessarily en-
dorse their behavior of breaking into
systems. I never endorsed it.
But then Don Parker and others
got to me and said, “You really
should go and talk to the security ad-
ministrators and the law enforce-
ment folks and get their perspectives
on that.” I did and that reminded me
that there are a lot of folks out there
that have objectives that aren’t be-
nign. Today, I think the major threat
is coming from people who are in-
terested in making money or causing
damage or leaking intelligence or all
kinds of things that you really don’t
want to happen.
McGraw: I was at the National Acad-
emy of Science recently and someone
was talking about the way Amazon.
com’s systems have evolved—instead
of being engineered in a top-down
fashion, they’ve emerged as this
chaotic soup. They were one of the
first to adopt this new service-ori-
ented architecture idea. It’s interesting
when you have a system that’s in some
sense an organic thing—defending it
can be a lot more difficult than if engi-
neered a system in a top-down way.
Denning: Well, that’s what we’ve got
today. The whole Internet and com-
puter networks and everything have
just emerged over time. So that’s prob-
ably the reason why it’s very hard.
People have attempted this top-down
design of secure operating systems
since the very early days, probably the
’60s. That’s hard to do; when you fi-
nally get your product put together
and certified and all that, it’s going to
be very expensive. It’s going to be ob-
solete. It’s going to be slow.
McGraw: People used to the edge of
technology will say, “My goodness,
that seems like an Apple II from 1981.”
Denning: Right. In the meantime,
the rest of the technology has
marched on and you want it because
it’s a productivity enhancer. It allows
you to do things that you couldn’t do
before. You can communicate in
ways you couldn’t before.
This top-down approach to
building systems and security is great
and maybe works well in some small,
rather confined kinds of environ-
‘We have to accept that there’s always going
to be security issues. It’s not just Microsoft’s
problem. It’s not their fault.’
ments, but for the world at large and
the Internet it’s never going to work.
McGraw: I guess we’re sort of
www.computer.org/security/
Interview
doomed—maybe not doomed, but
at least relegated—to co-evolution
in terms of security, where we’re
caught in this constant arms race,
this attack–defense thing. Which, I
suppose, is why you believe that we
have to understand attacks as much
as we understand defense.
Denning: It’s the same in the physical
world. In the physical world, things
evolve. You get new technologies.
Automobiles came along and then
airplanes; all this comes along and it
introduces new security issues. They
don’t all get solved. So the world is a
vulnerable place and we just kind of
accept that and we try to achieve a
reasonable level of security and sta-
bility and so on, but it’s not perfect.
McGraw: We seem to be bubbling
along pretty well.
Denning: Yes, but the difference is
that there seems to be this expectation
with our computer networks that we
could do it all right and that there are
no vulnerabilities. To me, that’s just
crazy; it’s not realistic and we have to
accept that there’s always going to be
security issues. It’s not just Microsoft’s
problem. It’s not their fault.
McGraw: Oh, they’re going to solve
it with Vista, haven’t you heard?
Denning: They’re adapting. I’ve
been very impressed with what Mi-
crosoft has done over the years.
McGraw: Absolutely. Mike Howard’s
work has been good. I don’t know if
you know Mike or not, but he was a
previous Silver Bullet victim back in
episode six. I want to switch gears
pretty radically. I noticed your time
■ IEEE SECURITY & PRIVACY 13
 Interview

on the Big Sur Power Walk, which is

New nonmember rate a 21-mile walk, is trending down

over the last two years.

Denning: No! It’s been about the

of $29 for S&P magazine! same!

McGraw: I wonder whether 2007 is

IEEE Security & Privacy magazine is the premier magazine
for security professionals. Each issue is packed with
information about cybercrime, security & policy, privacy
and legal issues, and intellectual property protection.
S&P features regular contributions by
noted security experts, including Gary
McGraw & Bruce Schneier.
going to be a breakthrough year. Are
you going to break your 2005 record?
Denning: Our goal is just to enjoy it
out there, we have six and a half
hours. If it takes six and a half hours,
it’s no problem. It’s a nice walk. It’s
beautiful. There’s no reason to rush it.
McGraw: I’m jealous of that. Can I
come?

Top security professionals in the field share Denning: It’s already sold out. You
information you can rely on: can run the marathon though.

McGraw: I think you’re talking to

• Wireless Security the wrong guy. One last question:
What kind of advice would you give
• Intellectual Property to a young scientist who’s just start-
Protection and Piracy ing out in security?
• Designing for
Denning: My advice would be,
Infrastructure Security “Follow your interest, but follow the
• Privacy Issues law.” I’m very much against experi-
ments that break the law.
• Legal Issues
• Cybercrime
• Digital Rights Management Y ou can find additional podcasts
in the series, such as those fea-
turing Becky Bace or Microsoft’s
• Securing the Enterprise
Michael Howard, at www.computer.
• The Security Profession org/security/podcasts/ or www.
cigital.com/silverbullet/.
• Education
Gary McGraw is chief technology officer
of Cigital. His real-world experience is
grounded in years of consulting with
major corporations and software produc-

Save 59%! ers. McGraw is the author of Software

Security: Building Security In (Addison-
Wesley, 2006), Exploiting Software
(Addison-Wesley, 2004), Building Secure
Software (Addison-Wesley, 2001), and
five other books. McGraw has a BA in phi-

www.computer.org/ losophy from the University of Virginia

and a dual PhD in computer science and
cognitive science from Indiana University.
services/nonmem/spbnr He is a member of the IEEE Computer
Society Board of Governors. Contact him
at gem@cigital.com.

14 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007

 Guest Editor’s Introduction

A Surprise Party
(on Your Computer)?

T
he idea of malicious software as a potential threat could hardly

seem novel to even the most uninformed at the dawn of our

era of pervasive technology and global connectivity. The early

1970s ushered in the evolution of malicious software tech-

nologies, and their developers and users have since driven a

substantial portion of the research
and development agenda of the in-
formation security discipline.
Although the rules of the infor-
mation security “game” seem to
constantly change, the tools players
use have been the same for more
than 30 years: software artifacts and
a handful of security practices and
policies built on a few fundamental
principles borrowed from mathe-
matics, engineering, and econom-
ics. The offensive is based on a
plethora of software tools that are
loosely grouped under the all-
encompassing term of malware, one
of several neologisms that the
information security community
can claim as its own. Viruses,
worms, Trojan horses, key loggers,
dialers, stealth password sniffers,
Web traffic generators, advertise-
ment popup programs, exploits,
rootkits, botnets, and zombie
agents all live under the malware
umbrella definition.
This special issue of IEEE Security
& Privacy focuses on malware’s various
forms and the threats they pose to
modern networks. In putting to-
gether the issue, I sought out contri-
butions that discuss classification,
detection, containment, and removal
of malicious software, as well as ad-
vances in defensive artifacts to pre-
empt the associated threats of their
offensive counterparts. The search
was slightly biased toward the applied
research, practical implementations,
and field experiments that would give
our readers insight into the tactics cur-
rently in play in the malware game.
As this issue’s guest editor, I en-
joyed reading all the contribu-
tions—they proved insightful,
diverse, and imaginative while
maintaining a practical focus. De-
ciding which articles to include
wasn’t a simple task, given the broad
range of possible topics. The IEEE
S&P staff pushed the magazine’s
page length boundaries to the limit
to make room for five articles, and
I’m thankful that they did: the re-
sulting combination is, I hope, well
balanced and worthy of our reader-
ship’s various interests.
We start our journey with a prac-
tical study of the plausibility of mal-
ware proliferation over wireless
networks. In “Studying Bluetooth
Malware Propagation: The BlueBag
Project,” Luca Carettoni, Claudio
Merloni, and Stefano Zanero give a
detailed account of a combined
hardware and software artifact de-
signed to detect
and assess the
Bluetooth capa-
bilities of mobiles
devices in live
and highly popu-
lated scenarios.
Vanessa Gratzer
and David Naccache
take us to the microcosm of micro- IVÁN ARCE
controller firmware and embedded Core Security
operating systems in “Alien vs. Technologies
Quine.” A clever combination of
side-channel attacks and self-
mutating code—technical tricks
commonly associated with offensive
security patterns—exemplify how
malware-detection techniques can
benefit from software or hardware
features that are often perceived as de-
sign weaknesses.
Carsten Willems, Thorsten Holz,
and Felix Freiling address malware
identification and classification
from a behavioral-analysis per-
spective in “Toward Automated
Dynamic Malware Analysis Using
CWSandbox.” The authors des-
cribe the implementation and use of
a software tool that aims to automat-
ically identify malicious software bi-
naries captured “in the wild” using
sandboxing technology.

PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY 15
 Guest Editor’s Introduction
PURPOSE: The IEEE Computer Society is the world’s largest association of computing
professionals and is the leading provider of technical information in the field.
MEMBERSHIP: Members receive the monthly magazine Computer, discounts, and
opportunities to serve (all activities are led by volunteer members). Membership is
open to all IEEE members, affiliate society members, and others interested in the
computer field.
COMPUTER SOCIETY WEB SITE: www.computer.org
OMBUDSMAN: Call the IEEE Member Services toll-free number, +1 800 678 4333 (US) or
+1 732 981 0060 (international), or email help@computer.org.
EXECUTIVE COMMITTEE
President: Michael R. Williams*
President-Elect: Rangachar Kasturi;* Past
President: Deborah M. Cooper;* VP,
Conferences and Tutorials: Susan K.
(Kathy) Land (1ST VP);* VP, Electronic
Products and Services: Sorel Reisman
(2ND VP);* VP, Chapters Activities:
Antonio Doria;* VP, Educational Activi-
ties: Stephen B. Seidman;† VP, Publica-
tions: Jon G. Rokne;† VP, Standards
Activities: John Walz;† VP, Technical
Activities: Stephanie M. White;* Secre-
tary: Christina M. Schober;* Treasurer:
Michel Israel;† 2006–2007 IEEE Division V
Director: Oscar N. Garcia;† 2007–2008
IEEE Division VIII Director: Thomas W.
Williams;† 2007 IEEE Division V Director-
Elect: Deborah M. Cooper;* Computer
Editor in Chief: Carl K. Chang†
* voting member of the Board of Governors
† nonvoting member of the Board of Governors
BOARD OF GOVERNORS
Term Expiring 2007: Jean M. Bacon,
George V. Cybenko, Antonio Doria,
Richard A. Kemmerer, Itaru Mimura, Brian
M. O’Connell, Christina M. Schober
Term Expiring 2008: Richard H. Eckhouse,
James D. Isaak, James W. Moore, Gary
McGraw, Robert H. Sloan, Makoto Takiza-
wa, Stephanie M. White
Term Expiring 2009: Van L. Eden, Robert
Dupuis, Frank E. Ferrante, Roger U. Fujii,
Anne Quiroz Gates, Juan E. Gilbert, Don F.
Shafer
Next Board Meeting:
18 May 2007, Los Angeles
revised 29 Jan. 2007
16 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
EXECUTIVE STAFF
Associate Executive Director: Anne Marie
Kelly; Publisher: Angela R. Burgess; Asso-
ciate Publisher: Dick J. Price; Director,
Administration: Violet S. Doan; Director,
Finance and Accounting: John Miller
COMPUTER SOCIETY OFFICES
Washington Office. 1730 Massachusetts Ave.
NW, Washington, DC 20036-1992
Phone: +1 202 371 0101
Fax: +1 202 728 9614
Email: hq.ofc@computer.org
Los Alamitos Office. 10662 Los Vaqueros
Circle, Los Alamitos, CA 90720-1314
Phone: +1 714 821 8380
Email: help@computer.org
Membership and Publication Orders:
Phone: +1 800 272 6657
Fax: +1 714 821 4641
Email: help@computer.org
Asia/Pacific Office. Watanabe Building, 1-4-2
Minami-Aoyama, Minato-ku,
Tokyo 107-0062, Japan
Phone: +81 3 3408 3118
Fax: +81 3 3408 3553
Email: tokyo.ofc@computer.org
IEEE OFFICERS
President: Leah H. Jamieson; President-
Elect: Lewis Termin; Past President:
Michael R. Lightner; Executive Director
& COO: Jeffry W. Raynes; Secretary: Celia
Desmond; Treasurer: David Green; VP,
Educational Activities: Moshe Kam; VP,
Publication Services and Products: John
Baillieul; VP, Regional Activities: Pedro
Ray; President, Standards Association:
George W. Arnold; VP, Technical
Activities: Peter Staecker; IEEE Division V
Director: Oscar N. Garcia; IEEE Division
VIII Director: Thomas W. Williams;
President, IEEE-USA: John W. Meredith,
P.E.
Static binary analysis also plays a
role in attempts to detect the obfusca-
tion techniques that malware uses to
hide its nature. In “Using Entropy
Analysis to Find Encrypted and
Packed Malware,” Robert Lyda and
James Hamrock rely on information
theory basics to detect and classify
malware and then put their idea
through a test using a mixed collec-
tion of malicious and innocuous soft-
ware samples gathered over five years.
Finally, we come to the com-
puter science field, which provides
assistance in a different static analysis
approach. Danilo Bruschi, Lorenzo
Martignoni, and Mattia Monga use
code normalization, control-flow
graph extraction, and graph-iso-
morphism analysis to detect and
classify malware variants derived
from common self-mutating roots
in “Code Normalization for Self-
Mutating Malware.”
T hese five articles combine to pro-
vide a broad view of current
practical advances in the field. But
this special issue by no means consti-
tutes a comprehensive report of all
ongoing work—I encourage our
readers to follow up with contribu-
tions that will help us build up a more
complete playbook for the informa-
tion security community and attain a
better understanding about how to
solve the malware problem.
Iván Arce is chief technology officer and
cofounder of Core Security Technolo-
gies—an information security company
based in Boston. Previously, he worked
as vice president of research and devel-
opment for a computer telephony inte-
gration company and as information
security consultant and software devel-
oper for various government agencies
and financial and telecommunications
companies. Contact him at ivan.arce@
coresecurity.com.
Interested in writing for us? Log onto
Manuscript Central at https://mc.
manuscriptcentral.com/cs-ieee. Authors
must use Manuscript Central to upload
their submissions. First-time users must
create a new account.

Studying Bluetooth
Malware Propagation
The BlueBag Project
Current Bluetooth worms pose relatively little danger
compared to Internet scanning worms—but things might
change soon. The authors’ BlueBag project shows targeted
attacks through Bluetooth malware using proof-of-concept
codes and devices that demonstrate their feasibility.
hanks to its characteristics, Bluetooth is emerging
T as a pervasive technology that can support wire-
less communication in various contexts in every-
day life. For this reason, it’s important to
understand the potential risks linked with various wire-
less devices and communication protocols. At present,
the greatest level of diffusion exists in so-called smart
phones. These devices offer all the functions of cutting-
edge telephones while integrating those of advanced
handheld computers managed by operating systems such
as Symbian or Microsoft Windows Mobile.
Smart phones can send and receive SMSs, MMSs (mul-
timedia messages), and email, plus let users listen to MP3
files, watch videos, surf the Internet, play games, manage
agendas, synchronize and exchange data with their PCs,
and much more. Although they still constitute a niche
market, smart phones saw a growth rate of 100 percent per
year for the past five years, and according to projections re-
leased at the beginning of 2006 by ABI Research, a market
research company, they held 15 percent of the global cell
phone market by the end of 2006, which is equivalent to
123 million units sold, thanks to growing user requests for
applications such as mobile email, decreasing prices, and a
broader choice of models (www.abiresearch.com/products/
market_research/Smartphones).
Because smart phones are now very similar to PCs,
they’re simultaneously more vulnerable, more useful, and
more attractive for potential attack than older mobile
phones. This increased vulnerability is due to the pres-
ence of a system of evolved connectivity applications that
expose the phone (and the data it contains) to risks. For-
tunately, recent cell phone viruses haven’t caused signifi-
cant damage, except for the obvious inconveniences
PUBLISHED BY THE IEEE COMPUTER SOCIETY
Malware
created when the phone malfunc-
tions. This has led to the myth that Blue-
tooth malware is yet another form of viral code that
doesn’t pose any real or new security issues and which has
a relatively low chance of causing significant damage.
However, as we will show, the potential for the propaga-
LUCA
CARETTONI
AND CLAUDIO
M ERLONI
tion of dangerous Bluetooth malware indeed exists. Until Secure
now, a combination of lucky chances and various envi- Network Srl
ronmental difficulties sheltered us from the widespread
propagation of such epidemics, but we cannot simply STEFANO
keep crossing our fingers and hoping for the best. ZANERO
In this article, we focus on the new risks created by Politecnico di
the widespread presence of Bluetooth-enabled devices Milano
carrying both potentially sensitive data and vulnerability-
prone software. In particular, we show how this mix of
technologies could become a vehicle for propagating
malware that’s specifically crafted to extract informa-
tion from smart phones. We built a mobile, covert at-
tack device (which we call BlueBag) that demonstrates
how stealthy attackers can reach and infect a wide
number of devices.
Bluetooth technology
As a word or term, Bluetooth is now fairly common. The
literal meaning supposedly refers to the Viking Emperor
Harald (Blåtand, in Danish), who lived during the 10th
century AD and united the kingdoms of Denmark, Nor-
way, and Sweden (http://en.wikipedia.org/wiki/Harald
_I_of_Denmark). In fact, the Bluetooth protocol aims to
unify different wireless data-transmission technologies
among mobile and static electronic devices such as PCs,
cellular phones, notebooks, PDAs, DVD players, MP3
devices, TVs, Hi-Fis, cash registers, point-of-sale termi-
■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY 17
 Malware
nals, and even household appliances such as refrigerators
and washing machines.
Bluetooth is essentially an alternative to the traditional
infrared communication standards (the most famous
being IrDA, Infrared Data Association). Whereas IrDA
transmits data using infrared light waves, Bluetooth is
based on short-wave radio technology, which can trans-
mit data across physical obstacles without needing line of
sight.1 Bluetooth devices use the 2.4-GHz frequency
range (the same range that WiFi 802.11 technology uses):
the exact frequency spectrum used varies between coun-
tries due to national regulations.
Significant improvements over IrDA are the fact that it
requires neither a line of sight nor proper orientation of
devices; it offers the possibility of connecting multiple
devices and not just pairs, as well as an increased range of
connectivity. When individuals connect different Blue-
tooth devices together, they create personal area net-
works, or PANs (also called piconets in the Bluetooth
specification), which are small ad hoc networks that can
exchange data and information just as within regular
LANs. These improvements are also the key reasons that
Bluetooth can be used, for instance, to transport auto-
matically spreading malware. This isn’t true with IrDA
because it requires proper alignments between both the
transmitting and receiving devices, effectively avoiding
“casual” or unwanted interaction.
Bluetooth technology is characterized by low power
(from 1 to 100 milliwatts [mW]—a thousand times less
than the transfer power of a GSM cell phone) and a com-
munication speed of around 1 Mbit per second (Mbps).
With regard to power, Bluetooth devices can be grouped
in classes, each corresponding to a different reach:
• class 1 can communicate with Bluetooth devices in a
100 meters range;
• class 2 can communicate with Bluetooth devices up to
a 10 m range; and
• class 3 can communicate with Bluetooth devices with-
in a 1 m range.
Currently, most common devices belong to classes 2
and 3; laptops and cell phones, for instance, normally use
class 2 peripherals. Toward the end of 2004, a new imple-
mentation of the Bluetooth technology (version 2.0) was
released that allowed transfer speeds of up to 2 and 3
Mbps, as well as lower energy consumption. The new
protocol is also backward-compatible.
Security issues
Although the Bluetooth standard incorporates very ro-
bust security mechanisms2 that application developers
can use to create secure architectures, researchers have
discovered a series of theoretical glitches and possible at-
tacks in Bluetooth’s core specifications.3,4 The most seri-
18 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
ous of these5 can lead to a compromise of the crypto-
graphic algorithm protecting communication through
sniffing, but this attack is impractical because the attacker
must be present at the pairing of devices and then must
be able to sniff communications between them. This is
more difficult than it seems: Bluetooth divides the 2.4-
GHz spectrum range into 79 channels, through which
devices hop in a pseudorandom sequence that differs
from PAN to PAN. This is done both to avoid interfer-
ence among different PANs and to enhance security. In
fact, this inhibits common commercial Bluetooth hard-
ware from sniffing communications in a PAN it doesn’t
participate in (contrast this with common, off-the-shelf
WiFi hardware, which can be placed in monitor mode
and used for sniffing). A hardware sniffer can easily cost
in the range of US$10,000, which places this attack out
of reach for the common aggressor, but surely within the
reach of corporate spies. Provided to be able to sniff the
pairing, a tool exists for personal identification number
(PIN) cracking (www.nruns.com/security_tools.php).
As a possible solution, researchers have proposed alter-
nate implementations of Bluetooth with more secure
encryption algorithms.6
Specific attacks
Even if Bluetooth is theoretically quite robust, several
security issues have surfaced in various implementations
of the standard stack since late 2003. Among the existing
attacks, we can quote significant examples drawn from
www.trifinite.org, an organization that hosts informa-
tion and research in wireless communications:
• BlueSnarf. This type of attack uses the OBEX (object
exchange) Push service, which is commonly used to
exchange files such as business cards. BlueSnarf allows
an attacker to access the vulnerable device’s phone
book and calendar without authentication. A recently
upgraded version of this attack gives the attacker full
read–write access.
• Bluejacking. By carefully crafting the identification that
devices exchange during association, attackers can
transmit short deceitful text messages into authentica-
tion dialogs. Users can then be tricked into using their
access codes, thereby authorizing an aggressor to access
a phone book, calendar, or file residing on the device.
• BlueBug. This vulnerability permits access to the cell
phone’s set of “AT commands,” which let an aggressor
use the phone’s services, including placing outgoing
calls, sending, receiving, or deleting SMSs, diverting
calls, and so on.
• BlueBump. This attack takes advantage of a weakness in
the handling of Bluetooth link keys, giving devices that
are no longer authorized the ability to access services as
if still paired. It can lead to data theft or to the abuse of
mobile Internet connectivity services, such as Wireless
 Malware

Application Protocol (WAP) and General Packet

Radio Services (GPRS).
• BlueSmack. This denial-of-service (DoS) attack knocks
out certain types of devices; attackers can perform it
with standard tools.
• HeloMoto. A combination of BlueSnarf and BlueBug,
this attack’s name comes from the fact that it was origi-
nally discovered on Motorola phones.
• BlueDump. This attack causes a Bluetooth device to
dump its stored link key, creating an opportunity for
key-exchange sniffing or for another pairing to occur
with the attacker’s device of choice.
• CarWhisperer. This attack abuses the default configura-
tion of many hands-free and headset devices, which
come with fixed PINs for pairing and transmission.
• BlueChop. This DoS attack can disrupt any estab-
lished Bluetooth piconet by means of a device that
isn’t participating in it, if the piconet master supports
multiple connections.

These flaws demonstrate how, in many cases, attackers can

steal information from mobile devices, control them from a
distance, make calls, send messages, or connect to the Inter-
net. In computer systems, these problems are traditionally
resolved with the release and application of patches. That
same approach doesn’t extend to GSM handsets, however;
in most cases, a firmware update can be performed only at
service points and shops, not by users. Therefore, many
phones and firmwares can be vulnerable and in use long
after a vulnerability is discovered and a patch produced.
Some of these attacks are implemented in Blooover, a
proof-of-concept application that runs on Symbian cell
phones (www.trifinite.org/trifinite_stuff_blooover.html).
This counters the idea that attackers need laptops to ex-
ecute their attacks, therefore making themselves visible.
Most of these attacks can also be performed at a distance
using long-range antennae and modified Bluetooth
dongles; a Bluetooth class-2 device was reportedly able
to perform a BlueSnarf attack at an astounding distance
of 1.08 miles (www.trifinite.org/trifinite_stuff_lds.html).
Creating the BlueBag: A covert
attack and scanning device
Our goals in undertaking this survey were to gather data
on the prevalence of insecure devices to understand how
susceptible people are to simple social engineering at-
tacks, and to demonstrate the feasibility of attacks in se-
cured areas such as airports or office buildings.
To mount any type of attack without being noticed,
we needed to create a covert attack and scanning device,
which we later came to call the BlueBag (see Figure 1).
We envisioned a Linux-based embedded system with
several Bluetooth dongles to process many discovered de-
vices in parallel, using an omnidirectional antenna to im-
prove the range and cover a wide area. We needed both a
Figure 1. Luca Carettoni (left) and Stefano Zanero (right) with the
BlueBag trolley. The picture was taken during the survey at the Orio
Center shopping mall. Notice how inconspicuous the trolley is in
this context, particularly if you keep in mind that the mall is in front
of an airport.
hidden tool and an instrument that could easily be car-
ried around and still have a long battery life.
To fulfill these requirements, we created the BlueBag
by modifying a standard blue trolley and inserting a Mini-
ITX system (see Figure 2) with the following off-the-
shelf components:
• a VIA EPIA Mini-ITX motherboard (model
PD6000E; because it doesn’t have a fan, its power con-
sumption is reduced);.
• 256 MBytes of RAM in a DDR400 DIMM module;
• EPIA MII PCI backplate to extend the available on-
board USB connections from two to six;
• a 20-Gbyte iPod, with a 1.8-inch hard drive that can
resist an acceleration of up to 3gs;
• eight class-1 Bluetooth dongles with Broadcom chipsets
(some were connected to a four-port USB hub);
• a modified class-1 Linksys Bluetooth dongle (Cam-
bridge Silicon Radio chipset) modified with a Netgear
omnidirectional antenna with 5dBi gain.
• a picoPSU, DC-DC converter (this small power supply
can generate up to 120 watts at over 96 percent effi-
ciency); and
• a 12V-26Ah lead acid battery to power our lengthy sur-
veying sessions (up to 8 hours).

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 19

 Malware
Figure 2. The BlueBag open. Note the motherboard (top, left side)
and battery (bottom, left side) as well as the dongles (top, right
side) and the antenna (below the dongles).
The total cost to build such a device is approximately
US$750, demonstrating just how economical it is to cre-
ate a Bluetooth attack device.
The BlueBag runs on GNU/Linux OS (specifically,
we use the Gentoo distribution for its outstanding cus-
tomizability and performance), on top of which we
created a software infrastructure in Python that makes
it easy to devise, control, and perform survey sessions.
The software is completely multithreaded, and we can
use the available dongles to perform different tasks
concurrently. We implemented a simple but useful
dongle management and allocation scheme to dynam-
ically learn about available resources and lock them
when needed. By doing so, we can reserve specific
dongles to run applications that need to lock single
physical interfaces for some time (the “pand” daemon,
which allows us to establish connectivity over Blue-
tooth). The software is quite modular and was designed
with the typical producer/consumer pattern: produc-
ers put found devices in a queue, using the standard
utilities that come with BlueZ (the official Linux Blue-
tooth stack) in order to collect information. The soft-
ware also includes customized versions of well-known
Bluetooth information-gathering techniques such as
blueprinting (a method for remotely identifying Blue-
tooth-enabled devices, similar to OS fingerprinting).
A distinct thread manages the queue and assigns tasks to
different consumers.
We designed the BlueBag software suite to allow us
to monitor and control the test’s execution from a palm-
top or smart phone via a Web interface that runs on top
20 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
of a TCP/IP over Bluetooth connection. Using this
configuration, there’s no need to open the BlueBag case
in public. At no time did anyone stop us or suspect us of
doing something unusual, even in highly secured areas
such as airports.
Survey results:
A discomforting landscape
In our surveys, we initially focused on identifying how
many active Bluetooth devices were in discoverable (or
visible) mode. This is, in fact, the condition of poten-
tial real-world risks: researchers have demonstrated that
it’s possible to find devices with active Bluetooth tech-
nology in nondiscoverable mode using a brute-force
attack. However, given the enormous time expendi-
ture this would entail, it isn’t feasible in a generic con-
text. An attack with this method is possible only if
attackers want to target a specific device they know to
be active and in range, and even then, they must first
identify the brand and model in order to prune the ad-
dress space.
Therefore, keeping a phone in nondiscoverable mode
provides a basic form of protection against targeted at-
tacks, and, in general, keeps the device safe from worms
that use Bluetooth technology to replicate, given that
such worms research their victims by simply scanning de-
vices in the area. For this reason, our test focused exclu-
sively on detecting devices in discoverable mode—the
only ones actually in a condition of potential risk of attack
from Bluetooth malware.
We conducted our survey in several high-transit loca-
tions surrounding Milan:
• Milan’s Exhibition Centre, during the InfoSecurity
2006 trade show;
• the Orio Center Shopping Mall;
• the MM2 Cadorna Metro Station;
• the Assago MilanoFiori Office District;
• Milan’s Central Station;
• the Milan Malpensa Airport; and
• Politecnico di Milano Technical University, Leonardo
Branch.
We chose a variety of venues to better evaluate whether
and how the prevalence of potentially vulnerable targets
varied in different contexts populated by different peo-
ple. Milan’s Central Station, for instance, has a very het-
erogeneous user base (and a dense crowd—the station
serves 270,000 passengers on an average business day);
the Orio Center Shopping Mall on a Saturday is filled
with many young people and families, subjects who
might not be aware of the dangers linked with new tech-
nologies, as opposed to visitors and exhibitors at the Info-
Security trade show (which sees roughly 2,000 security
professionals a day).
 Malware

Table 1. Summary of surveying results.

LOCATION DATE DURATION (HH: MM) UNIQUE DEVICES DEVICE RATE
InfoSecurity 2006 02/08–10/06 4:42 149 0.53
Orio Center Shopping Mall 03/01–11/06 6:45 377 0.93
MM2 Metro Station 03/09/06 0:39 56 1.44
Assago Office District 03/09/06 2:27 236 1.60
Milan Central Station 03/09/06 1:12 185 2.57
Milan Malpensa Airport 03/13/06 4:25 321 1.21
Politecnico di Milano
Technical University 03/14/06 2:48 81 0.48
Total 22:58 1405

We performed multiple sessions, on different days, for
a total of 23 hours of scanning dispersed over seven days.
Table 1 shows the results; “unique devices” denotes the
number of unique devices in discoverable mode that we
found during a specific session, and “device rate” indi-
cates the average number of unique devices discovered
per minute.
This data shows the capillary diffusion of Bluetooth
technology in everyday life and also highlights the
huge number of potentially vulnerable devices we
found, even in such a short duration: at first glance,
Bluetooth seems to be an integral part of everyone’s
life, important not only for professional but also for
personal use. Note, too, that in terms of risk awareness
among the Central Station, the Milan Malpensa Air-
port (populated by a heterogeneous public), and the
Assago Office District (where most users use these
devices for work purposes), there’s an insignificant dif-
ference. The situation was significantly better—indi-
cating a greater awareness among users—at the
InfoSecurity conference and at the university.
Categorizing devices
For the 1,405 unique devices detected, we performed
further analysis to broadly categorize the devices: cell
and smart phones (1,312), PCs/notebooks (39), Palm
Pilots (21), GPS navigators (15), printers (5), and other
various devices (13). In a similar, independent experi-
ment that FSecure performed in parallel during CeBIT
2006 (the ICT trade show in Hannover, Germany), a
regular laptop device capable of identifying active
Bluetooth devices in a 100-meter range found more
than 12,500 devices with discoverable Bluetooth mode
during a week of scanning (www.f-secure.com/
weblog/archives/archive-032006.html). To our know-
ledge, the researchers made no attempt to break down
the data any further.
After grouping the devices, we also tried analyzing the
types of services the devices offered and, in particular,
those that can be used to propagate worms. As Table 2
shows, the OBEX Push service was active and in range
Table 2. Services offered by mobile devices.
SERVICE TYPE NUMBER OF DEVICES
OBEX Object Push, OBEX file transfer 313
Headset hands-free audio gateway 303
Dial-up networking 292
for enough time to allow the scanning of 313 devices; this
service is normally used for transferring information
(business cards, for instance) or files and applications—
including worms. It’s very likely that most, if not all, cell
phones have the OBEX Push service activated. Because
we found 1,312 phones among the devices, the result
might seem strange at first sight. The explanation is sim-
ple: among all those devices, 313 stayed in range long
enough to allow the OBEX Push service to let BlueBag
correctly poll them.
Visibility
Another important finding from our survey was “visibil-
ity time”—that is, the average time in which a device re-
mains in a potential attacker’s range, or the time in which
an aggressor could exploit the device. This time depends
substantially on the different activity patterns of people in
different contexts: for instance, at the Orio Center Shop-
ping Mall, the average time was 12.3 seconds, at the Po-
litecnico di Milano Technical University, 10.1, and in the
Milano Malpensa Airport, the time was 23.1 seconds. Of
course, in some cases, this time depends on the activity
pattern a hypothetical aggressor might carry out: at the
Politecnico, we deliberately avoided staying in a single
classroom for a long time, but an aggressor interested in a
specific target might very well do so, or he or she might
follow the target in an airport up to the gate (where most
people settle down to wait for boarding), thus extending
this time. Our estimated average visibility times are there-
fore interesting for casual contacts, such as the one im-
plied by casual worm transmission.
It’s important to point out that some cell phone mod-

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 21

 Malware
Envelope
Main
If ( inTarget() ){
P.run();
}else{
while( true ){
scanDevices();
propagate();
} Payload
} foresee an increase in attacks that aim not only to make a
scanDevices() run(){…}
– Inquire for neighbors
propagate()
– Obex PUSH or Attacks Lib
targetsList[]
– Array of {bt_addr, payload, payload_parameters}
Figure 3. Pseudocode of a Bluetooth worm with dynamic payloads
for targeted attacks.
els on the market are configured to be in discoverable
mode by default if the Bluetooth connection is activated,
thus requiring the user to manually modify the setting to
the secure, nondiscoverable mode. Other devices must
instead be manually brought to discoverable mode and
are automatically reset to nondiscoverable after a short
time period. Our survey showed this to be effective: just a
handful of the detected device models were of the latter
type, surely out of proportion with the respective market
shares. Because keeping devices in nondiscoverable
mode doesn’t prevent communication among paired de-
vices, keeping a phone in nondiscoverable mode
shouldn’t entail a heavy usability burden.
Social engineering
After we investigated how effectively Bluetooth malware
can propagate, we realized that we needed to also estimate
the success rate of the basic social engineering techniques
Bluetooth worms commonly use. Most existing worms
rely on the user accepting a file to propagate, so we wanted
to know the ratio of users who would accept an unknown
file transfer from an unknown source. To obtain this data,
we developed an OBEX Pusher, an add-on to our normal
survey scripts, which searches for all discoverable Blue-
tooth devices with OBEX Push support enabled and then
sends them a file. Using this tool (and transmitting an in-
nocuous image file), we found that an astounding 7.5 per-
cent of device owners carelessly accepted unknown file
transfers from unknown sources and were thus highly vul-
nerable to social engineering attacks.
Bluetooth-enabled
malware networks
Our experiments show that just a small percentage of peo-
ple today are aware of the risks incurred by using appar-
ently innocuous devices. Moreover, smart phones and
22 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
connected palmtops have become daily work tools for
people with medium to high levels of responsibility within
their organizations. This implies that these devices could
hold particularly interesting information that potential ag-
gressors might want, such as for industrial espionage.
All the elements are thus in place for a huge risk, to
both companies and individuals; we can almost certainly
mobile device unusable or connect it to premium-rate
telephone numbers but also target specific information
on the device.
The effort it takes to reach a target device is often
thought of as a form of protection. To prove this assump-
tion wrong, we created a network of viral agents that can
spread among mobile devices looking for a target, zero in
on it, and then report information back to the attacker.
Because such agents are targeted to a specific environ-
ment or person, it’s interesting to study the use of dy-
namic payloads that vary depending on the type of
infected device. We designed a proof-of-concept worm
infrastructure that uses an envelope-payload mechanism
(see Figure 3).
The envelope component is a piece of software that
can scan for Bluetooth devices and propagate to found
devices; it has a list of targets to propagate to and a set of
payloads that it can “deploy” on the targets. The payload
components can be any type of malicious code that we
want to execute on victim devices within the limits of cell
phone operating systems—examples include keyloggers,
audio recorders, and sniffers. A similar design pattern (in
a very different context) appears in the Metasploit frame-
work’s Meterpreter infrastructure.7
Such payloads can also use the high connectivity of
Bluetooth-enabled devices to transmit harvested infor-
mation back to the attacker (in much the same way that
common PC-based spyware does), for instance, using
the Internet email service or a sequence of MMSs. In
this way, the attacked device doesn’t need to be within
the attacker’s range to send the retrieved data. It’s not dif-
ficult then to envision an attacker that infects several de-
vices (during a morning commute, for example)
belonging to an organization’s employees, and then just
waits for one of these devices to reach and infect or at-
tack the device of the organization’s CEO. In other
words, attackers could create a botnet of Bluetooth-
enabled, remotely controlled zombie machines, which
they could then use to perform further attacks on de-
vices they couldn’t normally reach.
One of the barriers to mobile malware propagation
has historically been differences among various operating
systems and hardware platforms. This is becoming easier
to overcome because of the growing popularity of Java 2
Micro Edition (J2ME), which enables software authors
(and, correspondingly, malware authors) to create cross-
platform software for mobiles. We successfully imple-

mented our proof of concept in Java; it runs on any cell
phone compatible with Mobile Information Device
Profile (MIDP) 2.0 on which JSR-82 (the Java Bluetooth
API) is active.
Features that would make this worm really dangerous
(and that we therefore didn’t implement) are ways to auto-
execute with as little interaction with the device user as
possible. On Symbian phones, for instance, a worm can
overwrite system files due to various structural flaws in ac-
cess control. Otherwise, implementation flaws and bugs
that allow for command execution (such as the ones we
described earlier) could help this worm propagate.
Simulation results
To correctly evaluate the threat this attack scenario poses,
we developed a model and a simulation to understand its
effectiveness. Due to space limitations, we refer the
reader to other work8,9 for a full discussion of the prob-
lems involved with modeling computer virus propaga-
tion. An excellent analysis of mathematics for infectious
diseases in the biological world is available elsewhere.10
Traditional propagation models
Propagation models evolve naturally, following the changes
in viruses’ propagation vectors. The earliest models targeted
virus propagation through the infection of host executa-
bles.11 Most biological epidemiological models share two
assumptions: they’re homogeneous—that is, an infected in-
dividual is equally likely to infect any other individual—and
they’re symmetric, which means there’s no privileged di-
rection of virus transmission. The former makes these
models inappropriate for illnesses that require noncasual
contact for transmission, as well as being inappropriate for
describing the early stages of propagation of an epidemic
that’s strongly location-dependent. In an influential seminal
paper, Jeffrey Kephart and Steve White addressed these
shortcomings by transferring a biological model onto a di-
rected random graph to better approximate the chain of
software distribution and the way it worked in the early days
of the personal computing revolution.11
Among other results, Kephart and White showed that
the more sparse a graph is, the more slowly an infection
on it spreads; there’s also a higher probability that an epi-
demic condition doesn’t occur. (In a sparse graph, each
node has a small, constant average degree; in a local graph,
the probability of having a vertex between nodes B and C
is significantly higher if both have a vertex connected to
the same node A.)
Mass mailers and scanning worms
The introduction of the Internet changed the malware
landscape and made traditional models unrealistic. The
first effect was the appearance of mass-mailing worms,
which demonstrated that tricking users into executing
the worm code attached to an email or exploiting a vul-
Malware
nerability in a common email client to automatically
launch it were successful ways to propagate viral code.
One of the best models for such propagation occurs
when the email service is modeled as an undirected
graph of relationships between people.12 The problems
here lie in how to model the users’ behavior,13 that is,
what to do if the worm doesn’t automatically exploit a
vulnerability but instead relies on social engineering,
and how to build the relationship graph (which is more a
local than a sparse one).
Eugene Spafford wrote the first description of self-
propagating worms that scan for vulnerabilities.14 In re-
cent years, such worms have changed the threat
landscape once more. They can be modeled through the
random constant spread (RCS) model,15 developed
using empirical data derived from the outbreak of the
Code Red worm, a typical random scanning worm.
This model uses extremely rough approximations, ig-
noring the effect of immunization and recovery. It im-
plicitly assumes that the worm will peak before a remedy
begins to be deployed. Additionally, it models the Inter-
net as an undirected, completely connected graph. This
is far from true,16 but the model still behaves macroscop-
ically well. UDP-based worms, however, require cor-
rections to account for bandwidth restrictions and
bottleneck Internet links.17
Bluetooth virus propagation can happen in several
different ways, but the most common until now has been
through simple social engineering. The worm sends
messages with copies of itself to any device in range
through an OBEX Push connection. The receiver, find-
ing a seemingly innocuous message on the cell phone
with an invitation to download and install an unknown
program, often has no clue that it can pose a danger.
Cabir, one of the first cell phone worms and the first case
of malware that could replicate itself solely through Blue-
tooth, used this technique.
MMS messages are another potential medium of
propagation. The Commwarrior worm propagated
through MMS (in fact, it spread from 8 a.m. to midnight
using Bluetooth connections and from midnight to 7
a.m. through MMS messages). Another method of prop-
agation would be the use of email- or TCP-based
worms, such as the ones usually seen on PCs, although
such methods haven’t really been used in phone viruses
until recently.
By the end of May 2006, F-Secure research laborato-
ries had classified more than 140 virus specimen (www.
f-secure.com/v-descs/mobile-description-index.shtml).
Of these, most found in the wild propagate by relying
solely on Bluetooth technology. In fact, our own experi-
ments showed that this transmission method alone can
reach 7.5 percent of a mixed population of targets, so we
decided to simulate the propagation of viral code that uses
Bluetooth as its vector.
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 23
 Malware
Output, Bluebag
No output
1.0 Output, no Bluebag
0.8
Infection ratio
0.6
0.4
0.2
0 500 1,000 1,500
Time (sec)
Figure 4. Infection ratio. Our simulation examined three different
conditions: without people entering or leaving the area, with a flow
of people and a propagating worm, and with a flow of people and
the BlueBag actively disseminating a worm.
This wasn’t an easy task. On one hand, we wanted to
follow the early stages of a worm’s propagation because
we wanted to evaluate its effectiveness as a targeted attack
tool instead of as a global infection (thus assumptions of
homogeneity and nonlocality can’t hold). On the other
hand, we needed to simulate the occasional and volatile
interactions of highly mobile devices. So we needed to
effectively simulate a highly sparse graph of relations that
change dramatically over time.
We used results from the ad hoc network research
community to simulate the transient geographical rela-
tionships caused by the movement of people in physical
places.18 Cecelia Mascolo and Mirco Musolesi’s CMM-
Tool generates realistic traces of movement for people
and their respective devices. We developed a small sim-
ulator that takes such feed as an input and then re-
produces the behavior of a Bluetooth worm that
propagates across them. The resulting BlueSim tool can
replicate, under various hypotheses, the behavior of real
worm propagation, taking into account the visibility
time of the devices, the inquire time needed, the data
transfer rate, and so on. We chose not to analyze layer-1
radio aspects such as collisions and interference prob-
lems, which could potentially occur in crowded places
with many devices; to do so, we would have needed a
complete network simulator such as NS, which in turn
would have required a lot more computational power to
complete even simple simulations.19
To evaluate how effectively a targeted worm can
propagate through a population, we recreated different
24 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
specific contexts with fixed parameters inspired from real
environment characteristics and data collected during
our survey. In particular, we simulated a shopping mall—
a simplified version of the Orio Center Shopping Mall
we visited—with 250  100 meters of surface and 78
shops. We considered a population of 184 discoverable
devices (7.5 percent of which were susceptible to infec-
tion), with a Bluetooth transmission range of 15 meters,
which is reasonable for mobile phones or PDAs. We con-
servatively estimated a 0.3-Mbps bandwidth link and a
42-Kbyte worm—the size of the envelope-and-payload
worm we designed.
In our first scenario, we used CMMTool to mimic the
behavior of people inside lunch areas or food courts, cre-
ating groups of relatively stationary people, a small num-
ber of whom “travel” among lunch areas. Figure 4 shows
the results. Initially, we didn’t consider people entering or
leaving the shopping mall during our simulation time (on
the line marked “no output”). We then added a random
flow of people with discoverable devices entering and
exiting the mall (on average, one person each 10 seconds,
a realistic value from our assessments). We then tested two
different conditions: the first was a worm propagating
(starting with just one infected device), marked “no
BlueBag” in the figure, and the second was the presence
of an attacker with a tool similar to our BlueBag, who was
actively disseminating a worm.
As Figure 4 shows, after little more than 30 minutes on
average (the time of a typical lunch break), a simple worm
could infect any susceptible device in the lunch area
through propagation alone. An attacker with a device
such as the BlueBag would obtain the result even faster.
In a second scenario, we considered the behavior of a
more mobile crowd of people walking in and out of shops
and browsing the window displays. In this case, the results
were similar, but they depended heavily on motion pat-
terns in the mall and were slower than in the food court
scenario (propagation speed was nearly halved in this case).
I n this work, we tried to envision possible future attack
scenarios involving targeted malware propagated
through Bluetooth-enabled covert attack devices. We
demonstrated the existence of a very high risk potential,
created by low awareness, ever-increasing functionalities
and complexity, and by the feasibility of targeted, covert
attacks through Bluetooth-enabled malware.
Possible future extensions of this work include better
planning of the malware’s “phone home” payload, to un-
derstand how likely it is for the collected data to reach the
attacker under various scenarios and how to improve
worm auto execution and process hiding. The creation
of a Bluetooth-only command and control infrastructure
would be a challenging evolution because it would inte-
grate ad hoc networking issues in our work.

Like common worms, our malware doesn’t currently
use Bluetooth attacks to spread itself: in the future, we
want to investigate whether we can use a sort of attack li-
brary, combining social engineering attacks and Blue-
tooth technology attacks.
Another possible extension would be the use of Blue-
Bag as a honeypot, to “capture” Bluetooth worms in the
wild and measure their real prevalence. We briefly en-
gaged in this activity, but more extensive testing is needed
to give reasonable statistical results.
Acknowledgments
An earlier version of this work was presented at the Black Hat conference
(www.blackhat.com). We thank Jeff Moss and the Black Hat staff for
their support. F-Secure, an antivirus vendor based in Helsinki, Fin-
land, and Secure Network, a security consulting and training firm based
in Milano, Italy, jointly funded the early stages of the BlueBag project.
One of the authors had partial support from the Italian Ministry of Uni-
versity and Research under the FIRB-PERF Project, in the research
unit led by Giuseppe Serazzi, whose support we gratefully acknowl-
edge. We warmly thank Martin Herfurt, Marcel Holtman, and Adam
Laurie, authors of the earliest works on Bluetooth security issues, for
their comments on this work. We also thank Mirco Musolesi (UCL)
and Paolo Costa (DEI - Politecnico di Milano) for their help with mod-
eling movement. Several people helped with various stages of this pro-
ject, including Alvise Biffi, Laura Mantovani, Miska Reppo, and
Mara Rottigni. Finally, we thank the anonymous reviewers for their
helpful and extensive reviews of the first draft of this article.
References
1. R. Morrow, Bluetooth Implementation and Use, McGraw-
Hill Professional, 2002.
2. C. Gehrmann, J. Persson, and B. Smeets, Bluetooth Secu-
rity, Artech House, 2004.
3. M. Jakobsson and S. Wetzel, “Security Weaknesses in
Bluetooth,” Proc. 2001 Conf. Topics Cryptology (CT-RSA
01), Springer-Verlag, 2001, pp. 176–191.
4. S.F. Hager and C.T. Midkiff, “Demonstrating Vulnera-
bilities in Bluetooth Security,” Proc. IEEE Global Telecom-
munications Conf. (GLOBECOM 03), vol. 3, 2003, IEEE
CS Press, pp. 1420–1424.
5. Y. Shaked and A. Wool, “Cracking the Bluetooth Pin,”
Proc. 3rd Int’l Conf. Mobile Systems, Applications, and Ser-
vices (MobiSys 05), ACM Press, 2005, pp. 39–50.
6. P. Hamalainen et al., “Design and Implementation of an
Enhanced Security Layer for Bluetooth,” Proc. 8th Int’l
Conf. Telecommunications (ConTEL 2005), vol. 2, 2005,
IEEE CS Press, pp. 575–582.
7. K.K. Mookhey and P. Singh, “Metasploit Framework”;
www.securityfocus.com/infocus/1789, July 2004.
8. S.R. White, “Open Problems in Computer Virus
Research,” Proc. Virus Bulletin Conf., 1998.
9. E. Filiol, M. Helenius, and S. Zanero, “Open Problems
in Computer Virology,” J. Computer Virology, vol. 1, nos.
3–4, 2006, pp. 55–66.
Malware
10. H.W. Hethcote, “The Mathematics of Infectious Dis-
eases,” SIAM Rev., vol. 42, no. 4, 2000, pp. 599–653.
11. J.O. Kephart and S.R. White, “Directed-Graph Epidemi-
ological Models of Computer Viruses,” Proc. IEEE Symp.
Security and Privacy, 1991, IEEE CS Press, pp. 343–361.
12. C.C. Zou, D. Towsley, and W. Gong, Email Virus Prop-
agation Modeling and Analysis, tech report, TR-CSE-03-
04, Univ. of Massachusetts, Amherst, 2003.
13. S. Zanero, “Issues in Modeling User Behavior in Com-
puter Virus Propagation,” Proc. 1st Int’l Workshop on the
Theory of Computer Viruses, 2006.
14. E.H. Spafford, “Crisis and Aftermath,” Comm. ACM,
vol. 32, no. 6, ACM Press, 1989, pp. 678–687.
15. S. Staniford, V. Paxson, and N. Weaver, “How to 0wn the
Internet in Your Spare Time,” Proc. 11th Usenix Security
Symp., (Security 02), Usenix Assoc., 2002, pp. 149–167.
16. A. Ahuja, C. Labovitz, and M. Bailey, Shining Light on
Dark Address Space, tech. report, Arbor Networks, Nov.
2001; www.arbornetworks.com/downloads/research38/
dark_address_space.pdf.
17. G. Serazzi and S. Zanero, “Computer Virus Propagation
Models,” M.C. Calzarossa and E. Gelenbe, eds, Tutorials
11th IEEE/ACM Int’l Symp. Modeling, Analysis and Sim-
ulation of Computer and Telecommunications Systems (MAS-
COTS 2003), Springer-Verlag, 2003.
18. M. Musolesi and C. Mascolo, “A Community-Based
Mobility Model for Ad Hoc Network Research,” Proc.
2nd ACM/SIGMOBILE Int’l Workshop on Multi-hop Ad
Hoc Networks: From Theory to Reality (REALMAN 06),
ACM Press, 2006, pp. 31–38.
19. C.-J. Hsu and Y.-J. Joung, “An Ns-Based Bluetooth
Topology Construction Simulation Environment,” Proc.
36th Ann. Symp. Simulation (ANSS 03), 2003, IEEE CS
Press, p. 145.
Claudio Merloni is a senior consultant for Secure Network S.r.l.,
an information security company based in Milan, Italy. His
research interests are auditing, policy development, and risk
assessment activities, particularly in a banking environment.
Claudio holds a MSc degree in computer engineering from the
Politecnico di Milano university. Contact him at c.merloni@
securenetwork.it.
Luca Carettoni is a senior consultant for Secure Network S.r.l., an
information security company based in Milan, Italy. His research
interests are in Web application security. A regular contributor of
OWASP-Italy, he has led penetration testing efforts on several
Italian and European banks. Luca holds a MSc degree in com-
puter engineering from the Politecnico di Milano university. Con-
tact him at l.carettoni@securenetwork.it.
Stefano Zanero holds a PhD in computer engineering from the
Politecnico of Milano university, where he is currently spending
a post-doc period. His research interests include the development
of intrusion detection systems based on unsupervised learning
algorithms, Web application security, and computer virology. He
is a member of the board of Journal in Computer Virology. Zanero
is a member of the IEEE and the ACM, and a founding member
of the Italian chapter of Information Systems Security Association
(ISSA). Contact him at stefano.zanero@polimi.it.
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 25
 Malware
Alien vs. Quine
Is it possible to prove that a computer is malware-free
without pulling out its hard disk? This article introduces a
novel hardware inspection technique based on the
injection of carefully crafted code and the analysis of its
output and execution time.
VANESSA n the Alien movie series, the fictional titular crea-
G RATZER
Université
Paris II
Panthéon-
Assas
I tures are a blood-thirsty species from deep space that
reproduce themselves as parasites. When a potential
host comes into close proximity of an alien egg, the
egg releases a creature that slides a tubular organ down the
victim’s throat, implanting its larva in his or her stomach.
In a matter of hours, the larva evolves and emerges from
DAVID the victim’s chest, violently killing the host. And then the
NACCACHE cycle starts all over again. Similarly, malware such as
École normale rootkits, worms, Trojans, and viruses penetrate healthy
supérieure computer systems and, once in, alter the host’s phenotype
or destroy its contents.
Detecting new malware species is a nontrivial task.1
In theory, the easiest way to exterminate malware is to
reformat the disk and then reinstall the operating system
(OS) from a trusted distribution CD. This procedure as-
sumes we can force computers to boot from trusted
media, but most modern PCs have a flash BIOS, which
means that the code component in charge of booting is
recorded on a rewritable memory chip. Specific pro-
grams called flashers—or even malware such as the CIH
(Chernobyl) virus—have the ability to update this chip.
This article addresses this concern, namely, ascertaining
that malware doesn’t re-flash the BIOS to derail disk-re-
formatting attempts or simulate their successful com-
pletion. Flash smart cards are equally problematic.
Consider a SIM card produced by Alice and sold empty
to Bob, who privately keys it. Alice reveals an OS code
but flashes a malware that simulates the legitimate OS.
When some trigger event occurs (maybe a specific chal-
lenge value sent during the authentication protocol),
the malware responds to Alice by revealing Bob’s key.
In biology, the term alien refers to foreign organisms
26 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE
introduced into a
locale. Alien species
usually wreak havoc on their new ecosystems because
they have no natural predators; a common way to eradi-
cate them is to deliberately introduce matching predators.
This is the approach we take in our research and that other
authors explore in related, yet different, publications.2,3
The arena
We tested our approach on Motorola’s 68HC05, a very
common 8-bit microcontroller (with more than 5 billion
units sold). We slightly modified the chip’s specifications
to better reflect a miniature PC’s behavior.
The 68HC05 has an accumulator A, an index register X,
a program counter PC (pointing to the executed memory
instruction), a carry flag C, and a zero flag Z indicating
whether the last operation resulted in a zero. We use (x) to
denote a function returning one if x = 0 and zero otherwise.
The platform has   216 = 65,536 memory bytes
denoted as M[0], …, M[ – 1]. The device interprets any
address a   as a mod . We model the memory as a
state machine insensitive to power off; upon shutdown,
execution fails and the machine’s RAM is backed up in
nonvolatile memory. Reboot restores RAM, resets A,
X, C, and Z, and launches execution at address 0x0002
(whose alias is start). The manufacturer records the
very first RAM state (the digital genotype) in non-
volatile memory. Then the device starts evolving, mod-
ifying its code and data as it interacts with the external
world.
The machine has two I/O ports (bytes) denoted In
and Out. Reading In lets a program receive data from
outside; assigning a value to Out displays this value out-
■ IEEE SECURITY & PRIVACY
 Malware

Table 1. The Motorola 68HC05 instruction set.

EFFECT lda i sta i bne k bra k

New A  M[i mod ]

New X 
New Z  (new A) (A)
Effect on M M[i + X mod ]  A
New PC  PC + 2 mod  PC + 2 mod   (PC, Z, k, )  (PC, 0, k, )
Opcode 0xB6 0xB7 0x26 0x20
Cycles 3 4 3 3

EFFECT inca incx lda ,X ldx ,X

New A  A + 1 mod 256 M[X]

New X  X + 1 mod 256 M[X]
New Z  (new A) (new X) (new A) (new X)
Effect on M
New PC  PC + 1 mod  PC + 1 mod  PC + 1 mod  PC + 1 mod 
Opcode 0x4C 0x5C 0xF6 0xFE
Cycles 3 3 3 3

EFFECT ldx i sta i, X lda i, X tst i

New A  M[i + X mod ]

New X  M[i mod ]
New Z  (new X) (A) (new A) (M[i mod ])
Effect on M M[i + X mod ]  A
New PC  PC + 2 mod  PC + 2 mod  PC + 2 mod  PC + 2 mod 
Opcode 0xBE 0xE7 0xE6 0x3D
Cycles 3 5 4 4

EFFECT ora i inc i stx i

New A  A  M[i mod ]

New X  (X)
New Z  (new A) (new M[i mod ])
Effect on M M[i mod ]  M[i mod ] + 1 mod 256 M[i mod ]  X
New PC  PC + 2 mod  PC + 2 mod  PC + 2 mod 
Opcode 0xBA 0x3C 0xBF
Cycles 3 5 4

side the machine. In and Out are located at memory cells
M[0] and M[1], respectively. Out’s value is restored on re-
boot (In isn’t). If the device attempts to write to In, exe-
cute In, or execute Out, execution halts. We assume that
the external world feeds incoming bytes synchronously
to the 68HC05’s clock domain.
The (potentially infested) system pretends to imple-
ment an OS function called Install(p): when given a
string p, Install(p) installs p at start. We don’t ex-
clude the possibility that malware might modify, mimic,
or spy on Install. Given that the next reboot will
grant p complete control over the chip, Install typi-
cally requires some cryptographic proof before in-
stalling p.
Table 1 reproduces some of the 68HC05’s instruc-
tions (the entire set appears in the microcontroller’s data
sheet.4) Here,  denotes the function that encodes short-
range jumps. The seventh bit of k indicates whether we
should regard k mod 128 as positive or negative, that is,
β(PC, z, k,  ) =
⎛ ⎛ ⎢ k ⎥⎞ ⎞
⎜ PC + 2 + (1 − z ) × ⎜⎝ k − 256 × ⎢ 128 ⎥⎟⎠ ⎟ mod .
⎝ ⎣ ⎦ ⎠

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 27

 Malware

start: ldx In ; XIn 0xBE 0x00 gram capable of such a behavior, under specific
bne store ; if X0 goto store 0x26 0x09 complexity constraints, is only the quine itself.
_______________________________________________________ In several aspects, the setting is analogous to
print: lda M,X ; AM[X] 0xE6 0x00 the scenario in the movie Alien vs. Predator, in
sta Out ; OutA 0xB7 0x01 which a group of humans (in our example, the
incx ; X++ 0x5C OS and legitimate applications) finds itself in the
bne print ; if X0 goto print 0x26 0xF9 middle of a brutal war between two alien species
bra start ; if X=0 goto start 0x20 0xF3 (in this case, malware and quine) in a confined en-
_______________________________________________________ vironment (the 68HC05).
store: lda In ; AIn 0xB6 0x00
sta M,X ; M[X]A 0xE7 0x00 Space-constrained quines
bra start ; goto start 0x20 0xED We start our space-constrained experiment by an-
alyzing Quine1.asm, a simple 19-byte program
that inspects  = 256-byte platforms (see Figure 1).
Figure 1. Quine1.asm. This simple 19-byte program stores and reads We used artificial horizontal lines to divide
memory contents. Quine1 into three functional blocks. A primitive
command dispatcher reads a byte from In and de-
termines if the verifier wants to read the device’s con-
Quines as malware predators tents (In = 0) or write a byte into the RAM (In  0).
A quine (named after the logician Willard van Orman As the program enters print, the index register is
Quine) is a program that prints a copy of its own code as null; print is a simple loop that sends 256 bytes out of
its only output.5,6 Writing quines is a tricky program- the device. As the loop ends, the device jumps back to
ming exercise that yields Lisp, C, or natural language ex- start to interpret a new command. The store block
amples such as queries a byte from the verifier, stores it in M[X], and re-
turns to start. Here’s the associated phenotyping 1:
((lambda (x) (list x (list (quote quote)
x)))(quote (lambda (x) (list x (list • Install(Quine1.asm) and reboot.
(quote quote) x))))) • Feed Quine1 with 235 random bytes to be stored at
M[21], , M[255].
char *f=”char*f=%c%s%c;main(){printf(f, • Activate print (command zero) and compare the ob-
34,f,34,10);}%c”; served output to
main() {printf(f,34,f,34,10);}
s1 = 0x00 0x00 0xBE 0x00 0x26 0x09
Copy the next sentence twice. 0xE6 0x00 0xB7 0x01 0x5C 0x26
Copy the next sentence twice. 0xF9 0x20 0xF3 0xB6 0x00 0xE7
0x00 0x20 0xED
To detect malware, we start by loading a quine onto M[21],…,M[255]
the computer that might have malware on it. This mal-
ware could neutralize the quine or even analyze it and But is Quine1.asm the only 19-byte program capable of
mutate (adapt its own code in an attempt to fool the veri- always printing s1 when subject to 1? We think so, al-
fier). As the download ends, we start a protocol called though we can’t provide a formal proof. To illustrate this
phenotyping on whatever survived inside the platform. difficulty, consider the slight variant to Quine1.asm in
Phenotyping lets us figure out whether the quine sur- Figure 2.
vived and whether it’s now in full control of the system. If For all practical purposes, the modification that results
it survived, we use it to reinstall the OS and eliminate it- in Quine2.asm has nearly no effect on the program’s
self; otherwise, we now know that the platform is in- behavior: instead of printing s1, this code will print:
fected. In extreme situations, decontamination by
software alone is impossible—a trivial example is mal- s2 = 0x00 0x00 0xBE 0x00 0x26 0x0B
ware that controls the I/O port and doesn’t let in any- 0x3D 0x06 0xE6 0x00 0xB7 0x01
thing new. Under such extreme circumstances, the 0x5C 0x26 0xF9 0x20 0xF1 0xB6
algorithms we discuss here can only detect the malware, 0x00 0xE7 0x00 0x20 0xEB
not eliminate it. M[23],…,M[255]
Upon activation, the quine will (allegedly!) start
dumping out its own code plus whatever else it finds on Let’s replace Quine2 with Quine3, where inc replaces
board. We then prove or conjecture that the unique pro- tst. When executed, inc will increment the memory

28 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007

 Malware

cell at label, which is inc’s own opcode. start: ldx In ; XIn 0xBE 0x00
However, inc’s opcode is 0x3C, so execution bne store ; if X0 goto store 0x26 0x0B
will transform 0x3C into 0x3D, which is tst’s label: tst label ; 0x3D 0x06
opcode. All in all, 2 doesn’t let us distinguish a ________________________________________________________
tst from an inc at label because both print: lda M,X ; AM[X] 0xE6 0x00
Quine2 and Quine3 will output s2. : : ; same code as in Quine1
This example’s subtlety shows that a micro-
processor-quine-phenotyping triple {, Q, }
rigorously defines a problem: given a state ma- Figure 2. Quine2.asm. This program shows a slight modification to
chine , find a state M (malware) that simulates Quine1.asm.
the behavior of a state Q (legitimate OS) when 
is subject to stimulus  (phenotyping). Security
practitioners can proceed by analogy to crypto- start: ldx In ; 3 cycles ; XIn (instruction I1)
systems whose specifications are published and stx Out ; 4 cycles ; OutX (instruction I2)
subject to public scrutiny. If we find an M simulat- : : ; ; other instructions
ing Q with respect to , a fix can either replace Q,
, or both. Note the analogy: given a stream ci-
pher  and a key Q (defining an observed cipher Figure 3. A small code fragment that echoes back a byte. This example
stream ), prove that the key Q has no equivalent executes in seven machine cycles.
keys M. An alternative solution involves proving
the quine’s behavior under the assumption that the
verifier is allowed to count clock cycles (state tran- start: ??? ??? ; 3 cycles ; an instruction causing •In
sitions if  is a Turing machine). st• Out ; 4 cycles ; an instruction causing Out•
: : ; ; other instructions
Time-constrained quines
Now let’s turn our attention to time constraints.
Consider the program in Figure 3 whose first Figure 4. The inferred form of the echo-back code fragment. Here, • stands for
instruction is located at start. register A or register X.
We latch a first value v1 at In and reboot; as
seven cycles elapse, v1 pops up at Out. If we turn
off the device before the eighth cycle and reboot, v1 reap- I2 ∈ sta Out stx Out sta ,X stx ,X .
pears on Out immediately. (Because Out is a memory
cell, its value is backed up upon power off.) Repeating To aim at Out (the address of which is 0x0001),
the process with values v2 and v3, we witness two seven- sta ,X and stx ,X would require an X=0x01, which
cycle transitions v1  v2 and v2  v3. is impossible (if the code takes the time to assign a value
It’s impossible to modify two memory cells in seven to X, it wouldn’t be able to compute the transition’s
cycles because all instructions capable of modifying a value by time). Hence, we infer that the code’s struc-
memory cell require at least four cycles. We’re thus as- ture looks like Figure 4, where • stands for register A or
sured that between successive reboots, the only memory register X.
changes are in Out. This means that no matter what the The only possible code fragments capable of causing
examined code is, it doesn’t have time to mutate in seven this behavior are
cycles, so it remains invariant between reboots.
The instructions other than sta and stx capable of adc In adc ,X add In add ,X
sta Out sta Out sta Out sta Out
directly modifying Out are ror, rol, neg, lsr, lsl,
I1
asl, asr, bset, bclr, clr, com, dec, and inc. Hence, ∈ lda In lda ,X ora In ora ,X
it suffices to select v2  dir(v1) and v3  dir(v2), where I2 sta Out sta Out sta Out sta Out
dir stands for any of the previous instructions to ascertain eor In eor ,X ldx In ldx ,X
that Out is modified by sta or stx (we also need v1  v2  sta Out sta Out stx Out stx Out
v3 to actually see the transition). Accordingly, v1 = 0x04,
v2 = 0x07, and v3 = 0x10 satisfy these constraints. We can’t further refine the analysis without more ex-
Because reading or computing with a memory cell periments, but we can already guarantee that as the exe-
takes at least three cycles, we have only four cycles left to cution of any of these fragments ends, the machine’s state
alter the contents of Out; consequently, the only sta and is either SA = {A = v3, X = 0x00} or SX = {A = 0x00, X =
stx instructions capable of making the transitions fast v3}. Now let’s assume that Out = v3 = 0x10. Consider
enough are the code in Figure 5:

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 29

 Malware

• Latch In  v4 = 0x02, reboot, and wait 14 cycles; A – opcode(sub,X) = 0x00 – 0xF0 = 0x10  0xF6
witness the transition 0x10  0x02  0xBE; and A opcode(and,X) = 0x00 0xF4 = 0x00  0xF6
then power off before the 15th cycle completes. A opcode(eor,X) = 0x00 0xF8 = 0xF8  0xF6
• Latch In  v6 = 0x04, reboot, and wait 14 cycles; wit- A  opcode(ora,X) = 0x00  0xFA = 0xFA  0xF6
ness the transition 0xBE  0x06  0xF6; and then A + opcode(add,X) = 0x00 + 0xFB = 0xFB  0xF6
power off before the 15th cycle completes.
Here, ldx ,X is impossible because it would cause a
To better understand what happens here, note that 0xBE is transition to opcode (ldx ,X) = 0xFE  0xF6 (if SX)
the opcode of ldx read from address 0x02, and 0xF6 is the or to 0x06 (if SA). I3 is thus identified as being necessar-
opcode of lda ,X read from address 0x06. ily lda ,X. It follows immediately that I4 = sta Out
Again, because v5  dir(v4) and v7  dir(v6), the second and that the 10 register-A-type candidates for {I1, I2}
transition is necessarily caused by some member of the sta are inconsistent. The phenotyped code is therefore one
or stx families and, more specifically, one of the following: of the following:
ldx In ldx ,X
I4 ∈ sta Out stx Out sta ,X .
 
I3 can’t be an instruction that has no effect on X and A be- stx Out
cause this will either inhibit a transition or cause a transi- lda ,X
tion to zero (remember that immediately before I3’s
sta Out
execution, the machine’s state is either SA or SX). This
rules out 18 jump instructions as well as all cmp, bit, Only the leftmost, namely ldx In, is capable of causing
cpx, tsta, and tstx variants. Moreover, lda i and ldx the observed transition 0x02  0xBE.
i are impossible as both would have forced 0x02 and Up to this point, we’ve built a proof that the device
0x04 to transit to the same constant value. In addition, v5 actually executed the first short fragment presented at the
 dir(v4) implies that I3 can’t be a dir variant operating beginning of this section. Extending the code as in Figure
on A or X, which rules out negx, nega, comx, coma, 6 and subjecting the chip to three additional experi-
rorx, rora, rolx, rola, decx, deca, dec, incx, ments, we observe
inca, clrx, clra, lsrx, lsra, lslx, lsla, aslx,
asla, asrx, and asra altogether. In  0x09 0xF6  0x09  0x5C
Because no carry was set, we sieve out sbc and adc,
whose effects will be strictly identical to sub i and add i; In  0x0A 0x5C  0x0A  0x26
in this case, add i, sub i, eor i, and i, and ora i are im-
possible because the system In  0x0B 0x26  0x0B  0xFA

⎧0x02 * x = 0xBE Note that the identified code just happens to let the
⎨
⎩0x06 * x = 0xF6 verifier inspect with absolute certainty the platform’s first
256 bytes. The verifier does a last time measurement, al-
has no solutions when operator * is substituted by +, –, lowing the quine to print the device’s first 256 bytes
, , or . Therefore, the only possible I3 candidates at (power off as soon as the last bne iteration completes, to
this point are avoid any malware hiding beyond address 0x000B). The
only thing left is to check the quine’s payload (the code
I3 ∈ sub ,X and ,X eor ,X between 0x000C and 0x00FF) and unleash the quine’s
add ,X lda ,X ldx ,X execution beyond address 0x000B.

But before I3’s execution, the machine’s state is

SA = {A = 0x06, X = 0x00} or
SX = {A = 0x00, X = 0x06}.
T his work raises several intriguing questions. Can this
approach be adapted to more complex and modern
architectures? Is it possible to prove security using only
space constraints? Can we modify the assembly lan-
It follows that the “,X” versions of sub, and, eor, ora, guage to allow or ease such proofs? Can space-
and add are impossible because constrained quines solve space-complete problems to
flood memory instead of receiving random data? Can
• if the device is in state SA, then 0x06*0x06  0xF6 for we design a formal microprocessor model and formally
* {–, , , , +}, and prove quine uniqueness?
• if the device is in state SX, then Another interesting challenge is the development of a

30 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007

 Malware

time-constrained quine whose proof doesn’t re- start: ldx In ; 3 cycles ; X  In

quire rebooting but, rather, the observation of stx Out ; 4 cycles ; OutX
one long succession of transitions. We think that lda ,X ; 3 cycles ; AM[X] (instruction I3)
such programs exist. A possible starting point sta Out ; 4 cycles ; OutA (instruction I4)
might be a code (not necessarily located at : : ; ; other instructions
start) similar to

loop: sta Out Figure 5. Analysis refinement. This code fragment echoes back an address and
lda In prints the address’s contents.
sta Out
ldx In
stx Out start:
lda ,X
sta Out print:
bne loop
Here, the idea is that the verifier will feed the
quine with values chosen randomly in a specific
set (thus ruling out dir variants) to repeatedly
explore the code’s immediate environment Figure 6. Additional experiments. This code fragment inspects the platform’s
until we acquire some degree of certainty. first 256 bytes.
If possible, this would have the advantage
of transforming the quine into a function that
we can automatically insert into any application
whose code requires authentication. Moreover, if we tect malware.
manage to constrain such a quine’s capabilities—that
is, not allow it to read data beyond a given offset—we
could offer the selective ability to audit critical pro-
gram parts while preserving the privacy of others. We
could audit an accounting program’s code, for exam-
ple, but keep secret signature keys provably out of the
quine’s reach.
Because time-constrained phenotyping is extremely
quick (a few clock cycles), preserves nearly all the plat-
form’s data, and requires only table lookups and compar-
isons, we’re currently trying to extend the approach
described here to more complex microprocessors and
implement it between chips in motherboards. We’re also
developing a second code authentication approach that
exploits power consumption patterns. Here, the designer
installs in the chip a function called sense(a) that loads
the contents of address a and “senses” it by executing a
predefined sequence of operations:
A  LookUpTable[
X  (((A  M[a]) 0x55) + 0xAA)
].
Because we expect this to cause a specific current con-
sumption pattern, our intent is to run sense(a) on the
entire memory space (including sense’s own code!)
and spot malware by analyzing the correlation be-
tween the power consumption of the potentially in-
fected platform and that of a malware-free device.
Hopefully, this will let us thoroughly inspect the con-
ldx In ; X  In 0xBE 0x00
stx Out ; Out  X 0xBF 0x01
lda ,X ; A  M[X] 0xF6
sta Out ; Out  A 0xB7 0x01
incx ; X  X+1 0x5C
bne print ; if X0 goto print 0x26
0xFA
tents of computing platforms and thus efficiently de-
References
1. T. Zeller, “The Ghost in the CD: Sony BMG Stirs a
Debate over Software Used to Guard Content,” The New
York Times, 14 Nov. 2005, p. C1.
2. C. Dwork, A. Goldberg, and M. Naor, “On Memory-
Bound Functions for Fighting Spam,” Proc. 23rd Ann.
Int’l Cryptology Conf. (CRYPTO 03), Springer-Verlag,
2003, pp. 426–444.
3. J. Garay and L. Huelsbergen, “Software Integrity Pro-
tection Using Timed Executable Agents,” Proc. ACM
Symp. Information, Computer and Comm. Security (ASI-
ACCS 06), ACM Press, 2006, pp. 189–200.
4. Motorola, 68HC(7)05H12, General Release Specifica-
tions, HC05H12GRS/D Rev. 1.0, Nov. 1998.
5. J. Burger, D. Brill, and F. Machi, “Self-Reproducing Pro-
grams,” Byte, vol. 5, Aug. 1980, pp. 74–75.
6. D. Hofstadter, Gödel, Escher, Bach: An Eternal Golden
Braid, Basic Books, 1999, pp. 498–504.
Vanessa Gratzer is a master’s student at the Université Paris II
Panthéon-Assas, Paris. Her research interests include forensics,
embedded technologies, and reverse engineering. Contact her
at vanessa@gratzer.fr.
David Naccache is a computer science professor at the Univer-
sité Paris II Panthéon-Assas, Paris, and a member of the Com-
puter Science Laboratory at the École normale supérieure. His
research interests include cryptography and embedded elec-
tronics. Naccache has a PhD in computer science from Ecole
nationale supérieure des télécommunications, Paris. Contact
him at david.naccache@ens.fr.

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 31

 Malware

Toward Automated Dynamic

Malware Analysis Using
CWSandbox

The authors present CWSandbox, which executes malware

samples in a simulated environment, monitors all system
calls, and automatically generates a detailed report to
simplify and automate the malware analyst’s task.

CARSTEN alware is notoriously difficult to combat be- We show how to

WILLEMS,
THORSTEN
HOLZ , AND
FELIX FREILING
University of
M cause it appears and spreads so quickly. Most
security products such as virus scanners
look for signatures—characteristic byte se-
quences—to identify malicious code. Malware, however,
has adapted to that approach. Poly- or metamorphic
Mannheim, worms avoid detection by changing their appearance, for
Germany example, whereas flash worms stealthily perform recon-
naissance without infecting vulnerable machines, waiting
to pursue strategic spreading plans that can infect thou-
sands of machines within seconds.
In the face of such automated threats, security re-
searchers can’t combat malicious software using manual
methods of disassembly or reverse engineering. There-
fore, analysis tools must analyze malware automatically,
effectively, and correctly. Automating this process
means that the analysis tool should create detailed re-
ports of malware samples quickly and without user
intervention. Analysts could then use the machine-
readable reports to initiate automated responses—auto-
matically updating an intrusion detection system’s
signatures, for example, and protecting networks from
new malware on the fly. An effective analysis tool
must log the malware’s relevant behaviors—the tool
shouldn’t overlook any of the executed functionality
because analysts will use the information to realistically
assess the threat. Finally, the tool should correctly ana-
lyze the malware—the sample should initiate every
logged action to avoid false positives.
In this article, we describe the design and implemen-
tation of CWSandbox, a malware analysis tool that fulfills
our three design criteria of automation, effectiveness, and
correctness for the Win32 family of operating systems.
use API hooking and
dynamic linked library (DLL) injection techniques to
implement the necessary rootkit functionality to avoid
detection by the malware. We acknowledge that these
techniques aren’t new; however, we’ve assembled the
techniques in a unique combination that provides a fully
functional, elegantly simple, and arguably powerful auto-
mated malware analysis tool.
Behavior-based malware analysis
Combining dynamic malware analysis, API hooking,
and DLL injection within the CWSandbox lets analysts
trace and monitor all relevant system calls and generates
an automated, machine-readable report that describes
• the files the malware sample created or modified;
• the changes the malware sample performed on the
Windows registry;
• which DLLs the malware loaded before execution;
• which virtual memory areas it accessed;
• the processes that it created;
• the network connections it opened and the informa-
tion it sent; and
• other information, such as the malware’s access to pro-
tected storage areas, installed services, or kernel drivers.
CWSandbox’s reporting features aren’t perfect—that
is, it reports only the malware’s visible behavior and not
how it’s programmed, and using the CWSandbox might
cause some harm to other machines connected to the
network. Yet, the information derived from the
CWSandbox for even the shortest of time periods is sur-

32 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY

prisingly rich; in most cases, it’s more than sufficient to
assess the danger originating from malware.
In the following paragraphs, we introduce the individ-
ual building blocks and techniques behind CWSandbox.
Dynamic malware analysis
Dynamic analysis observes malware behavior and ana-
lyzes its properties by executing the malware in a simu-
lated environment—in our case, the sandbox. Two
different approaches to dynamic malware analysis exist,
each resulting in different granularity and quality:
• taking an image of the complete system state before
malware execution and comparing it to the complete
system state after execution; and
• monitoring the malware’s actions during execution
with the help of a specialized tool, such as a debugger.
The first option is easier to implement but delivers
more coarse-grained results, which sometimes are suffi-
cient to gain an overview of what a given binary does.
This approach analyzes only the malware’s cumulative ef-
fects without taking into account dynamic changes—
such as the malware generating a file during execution
and deleting it before termination, for example. The sec-
ond approach is harder to implement, but we chose to use
it in the CWSandbox because it delivers much more de-
tailed results.
Dynamic analysis has a drawback: it analyzes only a
single malware execution at a time. In contrast, static mal-
ware analysis analyzes the source code, letting analysts
observe all possible malware executions at once. Static
analysis, however, is rather difficult to perform because
the malware’s source code isn’t usually available. Even if
it is, you can never be sure that undocumented modifi-
cations of the binary executable didn’t occur. Addition-
ally, static analysis at the machine code level can be
extremely cumbersome because malware often uses code-
obfuscation techniques such as compression, encryption,
or self-modification to evade decompilation and analysis.
API hooking
Programmers use the Windows API to access system re-
sources such as files, processes, network information, the
registry, and other Windows areas. Applications use the
API rather than making direct system calls, offering the
possibility for dynamic analysis if we can monitor the rel-
evant API calls and their parameters. The Windows
system directory contains the API, which consists of sev-
eral important DLLs, including kernel32.dll,
ntdll.dll, ws2 32.dll, and user32.dll.
To observe a given malware sample’s control flow, we
need to access the API functions. One possible way to
achieve this is by hooking—intercepting a call to a func-
tion. When an application calls a function, it’s rerouted
Malware
to a different location where customized code—the
hook or hook function—resides. The hook then per-
forms its own operations and transfers control back to
the original API function or prevents its execution com-
pletely. If hooking is done properly, it’s hard for the call-
ing application to detect the hooked API function or
that it’s called instead of the original function. In our
case, the malware could try to detect the hooking func-
tion, so we must carefully implement it and try to hide
the analysis environment from the malware process as
much as possible.
Several different methods let hook functions intercept
system calls from potentially malicious user applications
on their way to the kernel.1 For example, you can inter-
cept the execution chain either inside the user process in
one or multiple parts of the Windows API or inside the
Windows kernel by modifying the interrupt descriptor
table (IDT) or the system service dispatch table (SSDT).
Other methods have different advantages, disadvantages,
and complexity. We use in-line code overwriting because
it’s one of the more effective and efficient methods.
In-line code overwriting directly overwrites the
DLL’s API function code that’s loaded into the process
memory. Therefore, calls to the API functions are
rerouted to the hook function, regardless of when they
occur or whether they’re linked implicitly or explicitly.
Implicit linking occurs when an application’s code calls
an exported DLL function, whereas applications must
make a function call to explicitly load the DLL at runtime
with explicit linking. We can overwrite the function
code using the following steps:
1. Create a target application in suspended mode. Win-
dows loads and initializes the application and all im-
plicitly linked DLLs, but it doesn’t start the main
thread so the target application doesn’t perform any
operations.
2. When the initialization work is done, CWSandbox
looks up every to-be-hooked function in the DLL’s
export address table (EAT) and retrieves their code
entry points.
In the face of such threats, security
researchers can’t combat malicious
software using manual methods of
disassembly or reverse engineering.
3. Save the original code in advance so you can later re-
construct the original API function.
4. Overwrite the first few instructions of each API
function with a JMP (or a call) instruction that
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 33
 Malware

instruction to our hook code. In the hook function, we

Kernel32.dll-CreateFileA (*without* Hook):
can save the called API function’s parameters or modify
77E8C1F7 PUSH ebp them if necessary. Then, we execute the bytes that we
77E8C1F8 MOV ebp, esp overwrote in the first phase and then JMP back to execute
77E8C1FA PUSH SS:[ebp+8]
77E8C1FD the rest of the API function. There’s no need to call it
CALL +$0000d265
77E8C202
TEST eax, eax
with a JMP instruction: the hook function can call the
77E8C1FD
…
JNZ original API with a CALL operation and regain control
… when the called API function performs the RET. The
77E8C226
RET
hook function then analyzes the result and modifies it if
(a)
necessary. Holy Father offers one of the most popular and
Kernel32.dll-CreateFileA (*with* Hook): detailed descriptions of this approach,2 and Microsoft also
offers a library called Detours for this purpose (www.
77E8C1F7 JMP [CreatFileA-Hook] research.microsoft.com/sn/detours).
77E8C1FD
77E8C202
CALL +$0000d265 To offer a complete hooking overview, we must
TEST eax, eax
77E8C1FD JNZ +$05 mention system service hooking, which occurs at a
…
77E8C226
… 1 lower level within the Windows operating system and
RET
isn’t considered to be API hooking. Two additional pos-
Application.CreatFileA-Hook:
sibilities exist for rerouting API calls: we can modify an
entry in the IDT such that Int 0x2e, which is used for
2005EDB7 -custom hook code-
3 … … invoking system calls, points to the hooking routine, or
2005EDF0 JMP [CreatFileA-SavedStub] we can manipulate the entries in the SSDT so that the
system calls can be intercepted depending on the ser-
Application.CreatFileA-SavedStub: 2
vice IDs. We don’t use these techniques because API
21700000 PUSH ebp hooking is much easier to implement and delivers more
21700001 MOV ebp, esp
21700003 PUSH SS:[ebp+8]
accurate results. In the future, we might extend
21700006
JMP $77E8C1FD
CWSandbox to use kernel hooks because they’re more
(b)
complicated to detect.
On a side note, programs that directly call the kernel
Figure 1. In-line code overwriting. (a) shows the original function to avoid using the Windows API can bypass API hooking
code. In (b), the JMP instruction overwrites the API function’s first techniques. However, this is rather uncommon because
block (1) and transfers control to our hook function whenever the the malware author must know the target operating sys-
to-be-analyzed application calls the API function. (2) The hook tem, its service pack level, and other information in ad-
function performs the desired operations and then calls the vance. Our results show that most malware authors
original API function’s saved stub. (3) The saved stub performs the design autonomous-spreading malware to attack large
overwritten instructions and branches to the original API function’s user bases, so they commonly use the Windows API.
unmodified part.
DLL code injection
DLL code injection lets us implement API hooking in a
leads to the hook function. modular and reusable way. However, API hooking with
5. To complete the process, hook the LoadLibrary inline code overwriting makes it necessary to patch the
and LoadLibraryEx API functions, which allow application after it has been loaded into memory. To be
the explicit binding of DLLs. successful, we must copy the hook functions into the
target application’s address space so they can be called
If an application loads the DLL dynamically at runtime, from within the target—this is the actual code injec-
you can use this same procedure to overwrite the function tion—and bootstrap the API hooks in the target appli-
entry points. The CWSandbox carries out these steps in cation’s address space using a specialized thread in the
the initialization phase to set up the hooking functions. malware’s memory.
Figure 1a shows the original function code for How can we insert the hook functions into the
CreateFileA, which is located in kernel32.dll. process running the malware sample? It depends on the
The instructions are split into two blocks: the first marks hooking method we use. In any case, we have to manip-
the block that we’ll overwrite to delegate control to our ulate the target process’s memory—changing the appli-
hook function; the second block includes the instruc- cation’s import address table (IAT), changing the loaded
tions that the API hook won’t touch. Figure 1b shows the DLLs’ export address table (EAT), or directly overwriting
situation after we installed the hook. We overwrite the the API function code. In Windows, we can implant and
first six bytes of each to-be-analyzed function with a JMP install API hook functions by accessing another process’s

34 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007


virtual memory and executing code in a different
process’s context.
Windows kernel32.dll offers the API functions
ReadProcessMemory and WriteProcessMemory,
which lets the CWSandbox read and write to an arbi-
trary process’s virtual memory, allocating new memory
regions or changing an already allocated memory re-
gion’s using the VirtualAllocEx and Virtual-
ProtectEx functions.
It’s possible to execute code in another process’s con-
text in at least two ways:
• suspend one of the target application’s running threads,
copy the to-be-executed code into the target’s address
space, set the resumed thread’s instruction pointer to the
copied code’s location, and then resume the thread; or
• copy the to-be-executed code into the target’s address
space and create a new thread in the target process with
the code location as the start address.
With these building blocks in place, it’s now possible to
inject and execute code into another process.
The most popular technique is DLL injection, in
which the CWSandbox puts all custom code into a DLL
and the hook function directs the target process to load
this DLL into its memory. Thus, DLL injection fulfills
both requirements for API hooking: the custom hook
functions are loaded into the target’s address space, and
the API hooks are installed in the DLL’s initialization rou-
tine, which the Windows loader calls automatically.
The API functions LoadLibrary or LoadLibrary-
Ex perform the explicit DLL linking; the latter allows
more options, whereas the first function’s signature is
very simple—the only parameter it needs is a pointer to
the DLL name.
The trick is to create a new thread in the target
process’s context using the CreateRemoteThread
function and then setting the code address of the API
function LoadLibrary as the newly created thread’s
starting address. When the to-be-analyzed application
executes the new thread, the LoadLibrary function is
called automatically inside the target’s context. Because
we know kernel32.dll’s location (always loaded at
the same memory address) from our starter application,
and know the LoadLibrary function’s code location,
we can also use these values for the target application.
CWSandbox architecture
With the three techniques we described earlier set up,
we can now build the CWSandbox system that’s capa-
ble of automatically analyzing a malware sample. This
system outputs a behavior-based analysis; that is, it exe-
cutes the malware binary in a controlled environment
so that we can observe all relevant function calls to the
Windows API, and generates a high-level summarized
Malware
report from the monitored API calls. The report pro-
vides data for each process and its associated actions—
one subsection for all accesses to the file system and
another for all network operations, for example. One of
our focuses is on bot analysis, so we spent considerable
effort on extracting and evaluating the network con-
nection data.
After it analyzes the API calls’ parameters, the sand-
box routes them back to their original API functions.
Therefore, it doesn’t block the malware from integrating
itself into the target operating system—copying itself to
the Windows system directory, for example, or adding
new registry keys. To enable fast automated analysis, we
execute the CWSandbox in a virtual environment so that
the system can easily return to a clean state after complet-
ing the analysis process. This approach has some draw-
backs—namely, detectability issues and slower
execution—but using CWSandbox in a native environ-
ment such as a normal commercial off-the-shelf system
with an automated procedure that restores the system to a
clean state can help circumvent these drawbacks.
The CWSandbox has three phases: initialization, exe-
cution, and analysis. We discuss each phase in more detail
in the following sections.
Initialization phase
In the initialization phase, the sandbox, which consists of
the cwsandbox.exe application and the cwmoni-
tor.dll DLL, sets up the malware process. This DLL
installs the API hooks, realizes the hook functions, and
exchanges runtime information with the sandbox.
The DLL’s life cycle is also divided into three phases:
initialization, execution, and finishing. The DLL’s main
function is to handle the first and last phases; the hook
functions handle the execution phase. DLL operations
are executed during the initialization and finishing
phases and every time one of the hooked API functions
is called. Additionally, the DLL informs the sandbox
when the malware starts a new process or injects code
into a running process. As Figure 2 shows, the sandbox
then injects a new instance of the DLL into the newly
created or existing process so that it captures all API calls
from this process.
Execution phase
If everything initializes correctly, malware processing re-
sumes and the execution phase starts. Otherwise, the
sandbox kills the newly created malware process and ter-
minates. During the malware’s execution, the sandbox
reroutes the hooked API calls to the referring hook func-
tions in the DLL, which inspects the call parameters, in-
forms the sandbox about the API calls in the form of
notification objects, and then delegates control to the
original function or returns directly to the application
performing the API call, depending on the type of API
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 35
 Malware
Malware application
Executes
cwmonitor.dll
Communication
Executes
cwsandbox.exe
Malware application child
cwmonitor.dll
Communication
Figure 2. CWSandbox overview. cwsandbox.exe creates a new
process image for the to-be-analyzed malware binary and then injects
the cwmonitor.dll into the target application’s address space. With
the help of the DLL, we perform API hooking and send all observed
behavior via the communication channel back to cwsandbox.exe.
We use the same procedure for child or infected processes.
function called. After the original API call returns, the
hook function inspects the result and might modify it be-
fore returning to the calling malware application.
Because the malware sample shouldn’t be aware that
it’s being executed inside a controlled environment, the
cwmonitor.dll implements some rootkit functional-
ity: all of the sandbox’s system objects are hidden from the
malware binary, including modules, files, registry entries,
mutual exclusion events (mutexes), and handles in gen-
eral. This at least makes it much harder for the malware
sample to detect the sandbox’s presence. (This approach
isn’t undetectable, but our evaluation results show that
CWSandbox generates valuable reports in practice.)
During the execution phase, heavy interprocess com-
munication (IPC) occurs between the cwmonitor.dll
and cwsandbox.exe. Each API hook function informs
the sandbox via a notification object about the call and its
parameters. Some hook functions require an answer from
the sandbox that determines which action to take, such as
whether to call the original API function. A heavy com-
munication throughput exists because each notification
object must transmit a large amount of data and several
DLL instances can exist. Besides the high performance
need, reliability is crucial because data must not be lost or
modified on its way. Thus, we had to implement a reli-
able inter-process communication (IPC) mechanism
with high throughput so we used a memory-mapped file
with some customizations that fit our needs.
The execution phase lasts for as long as the malware
executes, but the sandbox can end it prematurely when a
timeout occurs or if critical conditions require instant
termination of the malware.
Analysis phase
In the last phase, the sandbox analyzes the collected data and
36 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
generates an XML analysis report. To measure the report’s
accuracy, we examined several current malware binaries
and compared the results with reports generated by the
Norman Sandbox and Symantec via manual code analysis.
Because the CWSandbox analyzes live systems and
lets us observe how the malware binary interacts with
other processes, its results were more detailed than those
the Norman Sandbox provides. However, both tools gen-
erated reports that detected file system changes, registry
modifications, mutex creation, or process-management
actions. Only small differences between the tools exist—
the reports differed if the malware binary used a random
file name when it copied itself to another location, for
example. Moreover, a disadvantage of Norman Sandbox
is that only limited Internet connection is available; if the
malware tries to download additional content from a re-
mote location, Norman Sandbox detects it, but can’t au-
tomatically analyze the remote file. In contrast,
CWSandbox observes the download request and, if the
malware downloads and executes a file, performs DLL
injection to enable API hooking on the new process.
Compared with the reports from Symantec’s manual
code analysis, the sandbox reported the important ac-
tions, but it failed to detect small details and behavior
variants (the creation of certain event objects, for exam-
ple) because the corresponding API calls weren’t hooked
in the current implementation. By adding hooks to these
API calls, we could extend CWSandbox’s analysis capa-
bilities. Symantec’s manual code analysis didn’t contain
any details that weren’t in our analysis report.
We executed the malware sample for a specific time
period, so we used it to tune CWSandbox’s throughput.
We found that executing the malware for two minutes
yielded the most accurate results and allowed the malware
binary enough time to interact with the system, thus
copying itself to another location, spawning new
processes, or connecting to a remote server, and so on.
Large-scale analysis
We conducted a larger test to evaluate CWSandbox’s re-
port throughput and quality. We analyzed 6,148 malware
binaries that we collected in a five-month period be-
tween June and October 2006 with nepenthes, a honey-
pot solution that automatically collects autonomous
spreading malware.3 Nepenthes emulates the vulnerable
parts of a network’s services to the extent that an auto-
mated exploit is always successful. Autonomous spread-
ing malware such as bots and worms thus think that
they’ve exploited the system, but rather than infecting a
“victim,” they’re delivering to us a binary copy of the
malware. Thus, our test corpus is real malware spreading
in the wild; we’re sure that all of these binaries are mali-
cious because we downloaded them after successful ex-
ploitation attempts in nepenthes.
For the analysis process, we executed the sandbox on
 Malware

Related work in malware behavior analysis

S everal tools exist for automatically analyzing malicious software
behaviors. Despite some similarities, our CWSandbox has the
advantage of generating a detailed, behavior-based analysis report
and automating the whole process to a high degree.
The Norman SandBox (http://sandbox.norman.no) simulates an
entire computer and a connected network by reimplementing the
core Windows system and executing the malware binary within the
simulated environment. It’s also possible to execute the malware
binary with a live Internet connection. The company’s Web site
features implementation details, a description of the underlying
technology, and a live demo. Such environments are mostly trans-
parent to the malware, which can’t detect that they’re being
executed within a simulated environment. Yet, simulations don’t let
the malware processes interfere with, infect, or modify other
running processes because no other processes run within the simu-
lation. By not monitoring this interference, valuable information
might be missed. By using a real operating system as CWSandbox’s
base, we allow the malware samples to interfere with the system
with only the limited disturbance created by API hooking.
Another comparable approach is TTAnalyze.1 Like our sandbox,
TTAnalyze uses API hooking, but it differs from our solution in
basically one area: it uses the PC emulator QEMU2 rather than
virtual machines, which makes it harder for the malware to detect
that it’s running in a controlled environment (although it means
no significant difference for the analysis).
A different approach is Chas Tomlin’s Litterbox (www.wiul.
org), in which malware is executed on a real Windows system,
rather than a simulated or emulated one. After 60 seconds of exe-
cution, the host machine is rebooted and forced to boot from a
Linux image. After booting Linux, Litterbox mounts the Windows
partition and extracts the Windows registry and complete file list;
the Windows partition reverts back to its initial clean state. Litterbox
focuses on network activity, so it makes several dispositions of the
simulated network. During malware execution, the Windows host
connects to a virtual Internet with an IRC server running, which
answers positively to all incoming IRC connection requests. The tool
captures all packets to examine all other network traffic afterwards.
This approach is advantageous to CWSandbox because IRC con-
nections are always successful, whereas CWSandbox encounters
malware binaries whose associated C&C server is already mitigated.
However, because Litterbox takes only a snapshot of the infected
system, it can’t monitor dynamic actions such as the creation of
new processes. The Reusable Unknown Malware Analysis Net
(Truman; www.lurhq.com) takes a similar approach.
Galen Hunt and Doug Brubacher introduced Detours, a library
for instrumenting arbitrary Windows functions.3 We opted to
implement our own API hooking mechanism to have greater flexi-
bility and more control over the instrumented functions, but this
library makes it possible to implement an automated approach to
malware analysis that is similar to CWSandbox.
The concepts of system call sequence analysis and API hooking
are well-known in the area of intrusion detection. A typical
approach includes a training phase in which the IDS system
observes system calls of the complete system or specific processes
and creates a profile of “normal” behavior. During operation, the
system call sequences are compared against this profile; upon
detecting a deviation, the system sounds an alarm that indicates
an anomaly. Stephanie Forrest and her coauthors give one of the
earliest descriptions of this approach,4 and Steven Hofmeyr and
colleagues introduced a method for detecting intrusions at the
privileged processes level.5 System call sequence monitoring can
also facilitate process confinement as introduced with Systracer by
Provos.6 Within CWSandbox, we use system call sequence analysis
to observe the behavior of malware processes and construct
detailed reports by correlating the collected data.
References
1. U. Bayer, C. Kruegel, and E. Kirda, “TTanalyze: A Tool for Analyzing Malware,”
Proc. 15th Ann. Conf. European Inst. for Computer Antivirus Research (EICAR),
2006, pp. 180–192.
2. F. Bellard, “QEMU, A Fast and Portable Dynamic Translator,” Proc. Usenix
2005 Ann. Technical Conf. (Usenix 05), Usenix Assoc., 2005, pp. 41–46.
3. G.C. Hunt and D. Brubacher, “Detours: Binary Interception of Win32 Func-
tions,” Proc. 3rd Usenix Windows NT Symp., Usenix Assoc., 1999, pp.
135–143.
4. S. Forrest et al., “A Sense of Self for Unix Processes,” Proc. 1996 IEEE Symp.
Security and Privacy (S&P 96), IEEE CS Press, 1996, pp. 120–128.
5. S.A. Hofmeyr, S. Forrest, and A. Somayaji, “Intrusion Detection Using
Sequences of System Calls,” J. Computer Security, vol. 6, no. 3, 1998, pp.
151–180.
6. N. Provos, “Improving Host Security with System Call Policies,” Proc. 12th
Usenix Security Symp. (Security 03), Usenix Assoc., 2003, pp. 257–271.

two commercial off-the-shelf systems with Intel Pen-
tium IV processors running at 2 GHz and with 2 GBytes
of RAM. Each system ran Debian Linux Testing and had
two virtual machines based on VMware Server and
Windows XP as guest systems. Within the virtual ma-
chines, we executed CWSandbox, effectively running
four parallel environments. We stored the malware bina-
ries in a MySQL database to which our analysis systems
wrote all reports.
The antivirus engine ClamAV classified these samples
as 1,572 different malware types. Most of them were dif-
ferent bot variants, particularly of Poebot and Padobot.
Of the 6,148 samples, ClamAV classified 3,863 as mali-
cious, most likely because signatures for the remaining
binaries weren’t available. The antivirus engine should
have classified 100 percent of the samples as malicious,
but it detected only 62.8 percent in this case.
CWSandbox analyzed all these binaries in roughly 67

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 37

 Malware

Sample analysis report

A s Figure A illustrates, CWSandbox analysis reports are quite
detailed. They let analysts quickly estimate what a malware binary
does and whether it needs to be further analyzed manually. With the
behavior-based approach, we get a quick overview of the binary,

- <analysis cwsversion="Beta 1.83" time="22.11.2006 15:26:14"

file="94c87c1c05d8f9628b789bced23f9ab3.exe"
logpath="c:\analysis\log\94c87c1c05d8f9628b789bced23f9ab3.exe\run_1\">
- <calltree>
- <process_call filename="c:\94c87c1c05d8f9628b789bced23f9ab3.exe"
starttime="00:00.046" startreason="AnalysisTarget">
- <calltree>
<process_call filename="C:\WINDOWS\system32\qodxih.exe C:\WINDOWS\system32\qodxih.exe
1428 c:\94c87c1c05d8f9628b789bced23f9ab3.exe" starttime="00:05.765"
startreason="CreateProcess"/>
</calltree>
</process_call>
</calltree>
- <processes>
- <process index="1" pid="884" filename="c:\94c87c1c05d8f9628b789bced23f9ab3.exe"
filesize="173595" md5="94c87c1c05d8f9628b789bced23f9ab3" username="foobar"
parentindex="0" starttime="00:00.046" terminationtime="00:06.281" startreason=
"AnalysisTarget" terminationreason="NormalTermination" executionstatus="OK">
+ <dll_handling_section></dll_handling_section>
+ <filesystem_section></filesystem_section>
+ <mutex_section></mutex_section>
+ <registry_section></registry_section>
+ <process_section></process_section>
+ <system_info_section></system_info_section>

Figure A. CWSandbox analysis report. The report contains detailed information about the analyzed processes, including

hours: the effective throughput was more than 500 bina-
ries per day per instance, which is at least an order of mag-
nitude faster than human analysis. An analyst can use the
resulting report as a high-level overview and analyze the
binary deeper manually, if necessary.
Of the 324 binaries that tried to contact an Internet
relay chat (IRC) server, 172 were unique. Because we ex-
tracted information such as the IRC channel or passwords
used to access the command and control servers from the
samples, we were able to mitigate the botnet risk.
Additionally, 856 of the 6,148 samples contacted
HTTP servers and tried to download additional data from
the Internet. By observing how the malware handled the
downloaded data, we learned more about the infection
stages, which ranged from downloading executable code
to click fraud (automated visits to certain Web pages).
We observed 78 malware binaries that tried to use the
Simple Mail-Transfer Protocol (SMTP) as a communi-
cation protocol. We recorded the destination emails and
the message bodies, so we got complete information
about what the malware wanted to do, which let us de-
velop appropriate countermeasures.
More than 95 percent of the malware binary sam-
ples added registry keys to enable autostart mecha-
nisms. Mutexes are also quite common to ensure that
only one instance of the malware binary is running on
a compromised host. We commonly saw malware bi-
naries copy themselves to the Windows system folder.
These patterns let us automatically define suspect be-
havior, and we could extend CWSandbox to automat-
ically classify binaries as normal or malicious on the
basis of observed behaviors.
W e’ve shown that it’s possible to automate binary
analysis of current Win32 malware using CW-
Sandbox. Such a tool lets analysts learn more about current
malware, and the resulting analysis reports help the analyst

38 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007

 Malware

which is generally sufficient to extract the most important information. as well as submit samples for analysis. The system returns analysis
You can view complete sample reports at www.cwsandbox.org, reports via email.

+ <winsock_section></winsock_section>
</process>
- <process index="2" pid="1348" filename="C:\WINDOWS\system32\qodxih.exe C:\WIN-
DOWS\system32\qodxih.exe 1428 c:\94c87c1c05d8f9628b789bced23f9ab3.exe" filesize=
"-1" username="foobar" parentindex="1" starttime="00:05.765"
terminationtime="02:00.781" startreason="CreateProcess"
terminationreason="Timeout" executionstatus="OK">
+ <dll_handling_section></dll_handling_section>
+ <filesystem_section></filesystem_section>
+ <mutex_section></mutex_section>
+ <registry_section></registry_section>
+ <process_section></process_section>
+ <system_info_section></system_info_section>
+ <window_section></window_section>
- <winsock_section>
+ <connections_unknown></connections_unknown>
+ <connections_listening></connections_listening>
- <connections_outgoing>
- <connection transportprotocol="TCP" remoteaddr="208.99.207.143"
remoteport="8453" protocol="IRC" connectionestablished="1" socket="608">
- <irc_data username="DEU|7907101" nick="DEU|7907101">
<channel name="####test####" password="nikne" topic_deleted=":.join #a,#b,#c"/>
</irc_data>
</connection></connections_outgoing>

information about changes to the file system, the Windows registry, and the data sent via Winsock.

determine whether a manual analysis is necessary. In the
future, we plan to extend CWSandbox with kernel-based
hooking, which will let us monitor kernel mode rootkits
and other kernel-based malware. Futhermore, we intend
to explore the ways in which we can use the CWSandbox-
generated reports for malware classification.
References
1. I. Ivanov, “API Hooking Revealed,” The Code Project,
2002; www.codeproject.com/system/hooksys.asp.
2. Holy Father, “Hooking Windows API—Technics of
Hooking API Functions on Windows,” CodeBreakers J.,
vol. 1, no. 2, 2004; www.secure-software-engineering.
com/index.php?option=com_content&task=view&id
=54&Itemid=27.
3. P. Baecher et al., “The Nepenthes Platform: An Efficient
Approach to Collect Malware,” Proc. 9th Int’l Symp. Recent
Advances in Intrusion Detection (RAID 06), LNCS 4219,
Springer-Verlag, 2006, pp. 165–184.
Carsten Willems is a PhD student in the Laboratory for
Dependable Distributed Systems at the University of
Mannheim, Germany. His research interests include malware
research, including the analysis of Win32 malware. Willems
has a MS in computer science from RWTH Aachen University,
Germany. He is the author of CWSandbox, a tool for auto-
matic behavior analysis. His company, CWSE GmbH deals
with software development in IT security. Contact him at
cwillems@consolo.de.
Thorsten Holz is a PhD student in the Laboratory for Depend-
able Distributed Systems at the University of Mannheim, Ger-
many. His research interests include honeypots, botnets,
malware, and intrusion detection systems. Holz has an MS in
computer science from RWTH Aachen University, Germany. Con-
tact him at thorsten.holz@informatik.uni-mannheim.de.
Felix Freiling is a professor of computer science and heads the
Laboratory for Dependable Distributed Systems at the Univer-
sity of Mannheim, Germany. His research interests include the
theory and practice of dependability. Freiling has a PhD in com-
puter science from Darmstadt University of Technology, Ger-
many. Contact him at freiling@informatik.uni-mannheim.de.

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 39

 Malware
Using Entropy Analysis
to Find Encrypted and
Packed Malware
In statically analyzing large sample collections, packed and
encrypted malware pose a significant challenge to automating
the identification of malware attributes and functionality.
Entropy analysis examines the statistical variation in
malware executables, enabling analysts to quickly and
efficiently identify packed and encrypted samples.
ROBERT LYDA alware authors often use encryption or pack-
Sparta
JAMES
HAMROCK
McDonald
M ing (compression) methods to conceal their
malicious executables’ string data and code.
These methods—which transform some or
all of the original bytes into a series of random-looking
data bytes—appear in 80 to 90 percent of malware sam-
Bradley ples.1 This fact creates special challenges for analysts who
use static methods to analyze large malware collections, as
they must quickly and efficiently identify the samples and
unpack or decrypt them before analysis can begin. Many
tools, including the packing tools themselves, are generally
successful at automatically unpacking or decrypting mal-
ware samples, but they’re not effective in all cases. Often-
times, the tools fail to recognize and reverse the
transformation scheme or find the original entry point in
the malware binary. Many malware samples thus remain
packed or fully encrypted, and analysts must identify them
for manual analysis and reverse engineering.
The difficulty of recognizing these transformed bytes
can vary greatly, depending on the transformation
scheme’s strength and the original bytes’ statistical nature.
However, stronger transformation schemes—such as
Triple DES encryption—typically produce less pre-
dictable sequences. This principle serves as the basis for
Bintropy, a prototype binary-file entropy analysis tool
that we developed to help analysts conveniently and
quickly identify encrypted or packed malware. Bintropy
operates in multiple modes and is applicable to any file.
Here, we focus on files in the Windows Portable Exe-
cutable (PE) format, which comprises the format of the
majority of malware executables.
Bintropy uses an established entropy formula to calcu-
late the amount of statistical variation of bytes in a data
40 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE
stream. Specifically,
it sums the frequency
of each observed byte value (00h – FFh) that occurs in
fixed-length data blocks, and then applies the entropy for-
mula to generate entropy scores. Higher entropy scores
tend to correlate with the presence of encryption or com-
pression. Further, to compensate for the variety of known
packing and encryption tools and the varying degree of
transformations they produce, we developed a methodol-
ogy that uses Bintropy to discriminate between native exe-
cutables and those that have been packed or encrypted.
Our methodology leverages the results obtained from
training Bintropy over different sets of executable file types
to derive statistical measures that generalize each file type’s
expected entropy ranges. The methodology compares the
malware executable’s entropy traits—which Bintropy
computes—against the expected ranges to determine if
the malware is packed or encrypted.
Here, we describe the Bintropy tool and methodol-
ogy. We also discuss trends associated with malware en-
cryption and packing, which we discovered by applying
the tool and methodology to a corpus of 21,576 PE-
formatted malware executable files obtained from a lead-
ing antivirus vendor.
Approach and technical analysis
Following a description of entropy and its measurement,
we describe how we use entropy analysis to identify
packed or encrypted malware executables. We then offer
results from testing our methodology.
Entropy analysis
Information density, or entropy, is a method for measur-
■ IEEE SECURITY & PRIVACY

ing uncertainty in a series of numbers or bytes.2 In tech-
nical terms, entropy measures the level of difficulty or the
probability of independently predicting each number in
the series. The difficulty in predicting successive num-
bers can increase or decrease depending on:
• the amount of information the predictor has about the
function that generated the numbers, and
• any information retained about the prior numbers in
the series.
For example, suppose we had a sequence of n consecutive
numbers in a Fibonacci series, which is a sequence of
numbers computed by adding the successive sums of the
preceding two numbers in the series. If we had knowl-
edge of how the Fibonacci function worked or saw
enough numbers in the series to recognize the pattern,
we could predict the series’ next number with absolute
certainty. In effect, the entropy changes when the predic-
tor applies prior knowledge or relevant knowledge
gained to determine the probabilities of successive num-
bers in the series. Thus, receiving information about the
generator function reduces the entropy by the value of
the information received.3
Although a sequence of good random numbers will
have a high entropy level, that alone doesn’t guarantee
randomness. For example, a file compressed with a soft-
ware compressor—such as gzip or winzip—might have a
high entropy level, but the data is highly structured and
therefore not random.4 Simply observing entropy will
not necessarily provide enough information to let the
observer distinguish between encryption and compres-
sion unless the observer knows how the data was gener-
ated. We can compute the entropy of a discrete random
event x using the following formula2:
n entropy attributes and thus distinguish them from native
H ( x ) = − ∑ p(i ) log 2 p(i ) ,
i =1
where p(i) is the probability of the ith unit of information
(such as a number) in event x’s series of n symbols. This
formula generates entropy scores as real numbers; when
there are 256 possibilities, they are bounded within the
range of 0 to 8.
Bintropy: A binary entropy analysis tool
Bintropy is a prototype analysis tool that estimates the like-
lihood that a binary file contains compressed or encrypted
bytes. Specifically, the tool processes files by iterating
through fixed-length data blocks in the binary, summing
the frequency of each block’s observed byte values (00h –
FFh). From this, it calculates the block’s entropy score. In
addition to individual block entropy scores, Bintropy cal-
culates other entropy-related file attributes, including the
average and highest entropy scores. Finally, Bintropy for-
Malware
mulates an overall confidence score by using a rule-based
methodology to analyze the block entropy scores against a
set of predefined entropy attribute metrics.
Bintropy has two modes of operation. In the first, the
tool analyses the entropy of each section of PE-formatted
executables, as specified in the executable’s header. This
helps analysts determine which executable sections might
be encrypted or packed. A standard compiler-generated
PE executable has standard sections (such as .text, .data,
.reloc, .rsrc). However, many packing tools modify the
original executable’s format, compressing the standard sec-
tion’s code and data and collapsing them into the one or
two new sections. In this mode, Bintropy calculates an en-
tropy score for each section it encounters. It doesn’t calcu-
late a score for the header section, which in our experience
is unlikely to contain encrypted or compressed bytes.
Bintropy’s second operational mode completely ig-
nores the file format. Instead, it analyzes the entire file’s en-
tropy, starting at the first byte and continuing through to
the last. With a PE-formatted file, users can thus analyze
the entropy of code or data hidden at the end of a file or in
between PE-defined sections (cavities), which is where
stealthy file-infecting samples, such as W32/Etap (http://
vil.nai.com/vil/content/v_99380.htm), typically hide.
Entropy metrics and
confidence-scoring methodology
There are currently hundreds of different packing algo-
rithms, each of which employs popular compression
and/or encryption algorithms such as Huffman, LZW,
and polymorphism to protect executable files.5 However,
our entropy analysis objective is not to model the trans-
formations of any specific packing or encryption tool.
Rather, it is to develop a set of metrics that analysts can
use to generalize the packed or encrypted executable’s
(nonpacked or unencrypted) ones. As such, our method-
ology computes entropy at a naïve model level, in which
we compute entropy based only on an executable byte’s
occurrence frequency, without considering how the
bytes were produced.
Although a sequence of good
random numbers will have a high
entropy level, that doesn’t in itself
guarantee randomness.
Experiments. To develop a set of entropy metrics, we
conducted a series of controlled experiments using the
Bintropy tool. Our goal was to determine the optimal
entropy metrics for native executable files and files con-
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 41
 Malware
Table 1. Computed statistical measures based on four training sets.
DATA SETS AVERAGE 99.99% CONFIDENCE
ENTROPY INTERVALS (LOW TO HIGH)
Plain text 4.347 4.066 – 4.629
Native executables 5.099 4.941 – 5.258
Packed executables 6.801 6.677 – 6.926
Encrypted executables 7.175 7.174 – 7.177
taining data transformations produced by encryption and
packing algorithms. The experiments consisted of four
separate tests, with training data sets for native, com-
pressed, and encrypted executable files, as well as a set for
plain text files for additional comparison.
The native training set consisted of 100 Windows 32-
bit PE executables, which we alphabetically selected
from the default “systems” folder on a Windows XP Ser-
vice Pack 2 OS environment. The packed training set rep-
resented a diverse set of packing algorithms; we
generated these executables by applying UPX (http://
upx.sourceforge.net), MEW1.1 (http://northfox.uw.
hu/index.php?lang=eng&id=dev), and Morphine 1.2
(www.hxdef.org) packing transformations to three sepa-
rate copies of the native executables. To generate the en-
crypted training set, we applied Pretty Good Privacy (PGP;
www.pgpi.org/doc/pgpintro) file encryption to the na-
tive executables.
We also performed a series of tests using different-
sized blocks. The tests determined that 256 bytes is an
optimal block size. Tests using larger block sizes, such as
512 bytes, tended to reduce the subjects’ entropy scores
when encryption existed only in small areas of the exe-
cutable. Our experiments also showed that executables
generally contain many blocks of mostly (or all) zero-
value data bytes, which compilers commonly generate to
pad or align code sections. This technique can greatly re-
duce an executable’s entropy score, because it increases
the frequency of a single value. To compensate for this
characteristic, we altered Bintropy to analyze only
“valid” byte blocks—that is, blocks in which at least half
of the bytes are nonzero.
Results. We applied the Bintropy tool to each of the four
training sets to compute individual entropy measures for
each set’s files. We configured Bintropy to process files in
256-byte-sized blocks and to ignore the executables’ for-
mat. For each file, the tool computed an average entropy
score and recorded the highest block entropy score.
Using standard statistical measures, we then aggregated
the data for each data set, computing each set’s respective
entropy and highest entropy score averages. For each data
set’s average and highest entropy scores, we computed a
confidence interval—the interval between two numbers
42 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
HIGHEST ENTROPY 99.99% CONFIDENCE
(AVERAGE) INTERVALS (LOW TO HIGH)
4.715 4.401 – 5.030
6.227 6.084 – 6.369
7.233 7.199 – 7.267
7.303 7.295 – 7.312
(low and high bounds) with an associated probability p.
We generated this probability from a random sampling of
an underlying population (such as malware executables),
such that if we repeated the sampling numerous times and
recalculated each sample’s confidence interval using the
same method, a proportion p of the confidence interval
would contain the population parameter in question.
Using the training data results (see Table 1), we derive
two entropy metrics based on the computed confidence
intervals for average and highest entropy. Using a 99.99
percent confidence level, executables with an average en-
tropy and a highest entropy block value of greater than
6.677 and 7.199, respectively, are statistically likely to be
packed or encrypted. These two values are the lower
confidence interval bounds of the entropy measures we
computed for packed executables, and form the basis for
our methodology for analyzing malware executables for
the presence of packing or encryption. If both the Bin-
tropy computed average file entropy and highest entropy
block score exceed these respective values, we label a
malware executable as packed or encrypted.
Limitations of the approach
It’s infeasible to absolutely determine if a sample contains
compressed or encrypted bytes. Indeed, Bintropy can pro-
duce both false positives and false negatives. False negatives
can occur when large executables—those larger than
500kbytes—contain relatively few encrypted or com-
pressed blocks and numerous valid blocks, thereby lowering
the executable file’s average entropy measure. False positives
can occur when processing blocks that score higher than
the packing confidence interval’s lower bound, but the
blocks’ bytes contain valid instruction sequences that coin-
cidentally have a high degree of variability.
Using the statistical results computed from our packed
training data set, we calculated our confidence-interval-
based methodology’s expected false positive rate. We
treated the packed data sets as a matched pairs t-distribu-
tion because the underlying system files were the same
and, therefore, the only randomization was that of the
packer. We used these intervals as the entropy filter on
unknown input samples. We applied a standard t-test to
the data set and calculated a Type I error’s significance
level—in this case, the false positive rate—to be 0.038
 Malware

percent. This value indicates the likelihood of an un- 1.0

packed or unencrypted sample passing through the con-
0.9
fidence-interval filter. To compute the expected false
negative rate, we calculated the statistical likelihood that a 0.8
pec2
packed sample falls outside our 99.99 percent confidence- 0.7
pec1
UPX2
interval range (that is, within the .01 percent range). Be- UPX1

cause we’re concerned only about packed executables
with entropy scores below the interval’s lower bounds,
we halve this value to obtain the expected false negative
rate of .005 percent.
Finally, sophisticated malware authors could employ
countermeasures to conceal their encryption or com-
pression use. For example, they could make encrypted
bytes generated using strong cryptography look less ran-
dom by padding the bytes with redundant bytes. They
could also exploit our approach by distributing en-
crypted bytes among invalid blocks, such that the blocks
remained invalid. Such countermeasures could reduce
the executable’s entropy score, and thereby limit Bin-
tropy’s effectiveness.
Entropy trends
As mentioned, we identified entropy trends by running
Bintropy and applying our confidence-interval method-
ology to a corpus of 21,567 malware Windows32-based
PE executables from a leading antivirus vendor’s collec-
tion from January 2000 to December 2005. We orga-
nized the resulting malware samples by the year and
month in which the vendor discovered them.
Our analysis computes the entropy of a malware exe-
cutable’s PE sections and analyzes the trends of packed or
encrypted PE sections (as identified by our methodol-
ogy) across a large time span. With the exception of the
header section, we analyzed all sections identified in the
malware executables. Further, we performed the analysis
without regard to any particular section’s purpose or
“normal” use. This enabled us to analyze code or data,
hidden in or appended to any of the identified sections.
Our trend analysis features the top 13 PE sections that
exceeded the packing lower-bound confidence interval
threshold in aggregate. These sections comprised eight
standard PE sections and five packer-generated sections.
The eight standard sections—.text, .data, .rsrc, .reloc, .rdata,
.idata, CODE, and DATA—are created by default by most
PE-generating compilers. The remaining five sections—
.aspack, UPX1, UPX2, pec1, and pec2 are created by
packing technologies that replace the default PE-formatted
sections and their bytes with custom ones. However, be-
cause other packers reuse the default sections, the packers
that created the nondefault sections highlighted in our
analysis are not necessarily the most prevalent packers in use.
Section packing trends over time
Figure 1 shows which sections were the most often
packed or encrypted for a given year. We calculated each
Section (%)
0.6 .aspack
DATA
0.5 CODE
.idata
0.4 .rdata
.reloc
0.3 .rsrc
.data
0.2 .text
0.1
0.0
2000 2001 2002 2003 2004 2005
Year
Figure 1. Percentage of encrypted or packed sections over a six-year
period. UPX1 was the most prevalent of the packed sections across
the period, followed by the .text section.
section’s percentages by totaling the section’s encrypted
or packed occurrences and dividing that number by the
total number of sections that were packed or encrypted
that year.
In 2000, .reloc was the most often packed or en-
crypted section. This section’s popularity steadily de-
clined across the remaining years, with only a slight
increase in 2005. The second most-packed section in
2000 was UPX1, which is generated by the very popular
UPX packing tool. Due to UPX’s prevalent use in nu-
merous W32/GAOBOT and W32/SPYBOT variants,
the presence of the UPX1 section in the data set increased
over the next few years, peaking in 2002. Thereafter, its
prevalence steadily decreased, but UPX1 remained the
most popular of all the sections we identified as packed
across this six-year period, followed by the .text section,
which is where the compiler writes most of a program’s
executable code.
Evidence of packing in the .rdata section increased
in popularity from 2000 through 2005. In 2000 and
2001, packing of the .text, .data, and .rsrc sections was
very prevalent, and then decreased in 2002; the sec-
tions then steadily increased to peak in 2005. Packing
in the CODE, DATA, and .idata sections show no clear
trends over the study period. UPX2, pec1, and pec2
were the least-prevalent of the sections we identified as
being packed; they were at their lowest in 2003 and
were relatively more popular at the time period’s be-
ginning and end.
Additional packing trends
Figure 2 shows the annual number of packed or en-

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 43

 Malware

1,800 This graph accounts for only those samples that were
2000 2001 2002 2003 2004 2005 above the packing confidence interval’s lower bound.
1,600
The overall average entropy value for all other non-
1,400
packed sections was approximately 4.1. The graph paints
Number of sections

1,200 a fairly consistent picture: entropy levels increased from

1,000 2000 through 2005 for nearly every section and type of
packing/encryption. The exceptions were the DATA
800
section and pec1, which trended up-down-up, and
600 pec2, which trended down. This data indicates that the
400 variability of the bytes that the packing and encryption
200
technologies produced generally increased throughout
the six-year period.
0
.text .data .rsrc .reloc .rdata .idata CODE DATA .aspack UPX1 UPX2 pec1 pec2
Section types

Figure 2. Number of encrypted sections by year. Packing of .text

section increased the most dramatically across the period.
O verall, the Bintropy tool proved useful for analyzing
and generating statistics on malware collections that
contained packed or encrypted samples. It analyzed PE
sections of the malware binaries in detail, providing a
quick statistical prediction of the existence of significant
3,000 data randomization, thereby accurately identifying
packed or encrypted malware samples. The tool was also
2,500 successful in identifying encrypted sections and provid-
ing statistical data on large-sized malware sample collec-
Total number sections

2,000 tions at a low level of detail.

1,500
1,000
500
0
.text .data .rsrc .reloc .rdata .idata CODE DATA .aspack UPX1 UPX2 pec1 pec2
Section types
Figure 3. Total number of encrypted sections over the six-year study
period. Packing of the .text and .UPX1 were the most prevalent
during this time period.
crypted sections for each section type. This graph clearly
shows the packing or encrypting trends of particular sec-
tions across the years. One of the most notable trends is
the increased packing of the .text, .data, .rsrc, and espe-
cially the .rdata sections across the period. It also shows
UPX1’s overall prevalence and the lack of a perceivable
trend for the CODE, DATA, and .idata sections.
Figure 3 is an accumulation of Figure 2’s data, show-
ing the most commonly packed and encrypted sections
over the six-year period. This graph helps delineate each
section’s exact popularity over the entire period com-
pared to the previous graphs. As Figure 3 shows, the six
most commonly packed sections, in order, were .text,
UPX1, .data, .rsrc. .idata, and .rdata.
Figure 4 depicts each section’s average entropy high-
scores attribute accumulated over the six-year period.
The advantage of using entropy analysis is that it offers
a convenient and quick technique for analyzing a sample
at the binary level and identifying suspicious PE file re-
gions. Once the analysis identifies sections of abnormal
entropy values, analysts can perform further detailed
analysis with other reverse-engineering tools, such as the
IDAPro disassembler.
Our research goal was to develop a coarse-grained
methodology and tool to identify packed and encrypted
executables. However, a more fine-grained approach
might be useful in identifying the particular transformation
algorithms that malware authors apply to their malware. To
improve Bintropy’s entropy computation beyond simple
frequency counting, such an approach might further ex-
amine the algorithms and the statistical attributes of the
transformations they produce to develop profiles or
heuristics for fingerprinting their use in malware.
Acknowledgments
The authors especially thank Jim Horning, David Wells, and
David Sames for their technical input and constructive feedback, which
helped to significantly improve this article.
References
1. T. Brosch and M. Morgenstern, “Runtime Packers: The
Hidden Problem,” Proc. Black Hat USA, Black Hat, 2006;
www.blackhat.com/presentations/bh-usa-06/BH-US-
06-Morgenstern.pdf.
2. C.E. Shannon and W. Weaver, The Mathematical Theory
of Communication, Univ. of Illinois Press, 1963.

44 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007

 Malware

Related work
U sing entropy to measure randomness or unpredictability in an
event sequence or series of data values is a well-accepted sta-
tistical practice in the fields of thermodynamics and information
theory.1,2 In malicious code analysis, researchers have used
entropy analysis in various applications. Julien Olivain and Jean
Goubault-Larrecq developed the Net-Entropy tool to identify
anomalous encrypted network traffic that might indicate a
network-based attack.3
Closer to our own research, a few tools analyze Portable
Executable (PE) file entropy. WinHex (www.winhex.com/winhex/
analysis.html) is a commercially available tool that uses entropy to
identify common file types, including plain text, jpeg, and binary.
Portable Executable Analysis Toolkit (PEAT) is a tool suite that lets
analysts examine a Windows PE file’s structural aspects.4 PEAT
provides byte-value entropy scores for each PE segment’s parti-
tioned section. It then normalizes these entropy values against
each window’s total entropy. This helps analysts identify section
portions that drastically change in entropy value, indicating
section-alignment padding or some other alteration of the original
file. To use PEAT effectively, analysts must have some domain
knowledge about PE files, viruses, and other system-level concepts,
as well as some experience working with PEAT.
We’ve extended PEAT’s segment entropy score approach and
created a detection tool for automatically identifying encrypted or
packed PE executables with a certain degree of confidence.
Bintropy has a similar fidelity of analysis capability, but accu-
mulates the information to provide a quick statistical prediction for
the existence of significant data randomization, which indicates
encryption or packing in large file collections that include exe-
cutable files. Analysts can also use Bintropy to perform a more in-
depth analysis of any particular PE-formatted file section.
Finally, a group of hackers developed and maintains the PEiD
analysis tool (http://peid.has.it). According to its Web site, the tool
can identify the signatures of more than 600 packing tools. PEiD
has an option for analyzing executable files’ entropy. However, its
developers don’t provide detailed documentation on its implemen-
tation or underlying methodology.
References
1. C.E. Shannon and W. Weaver, The Mathematical Theory of Communication,
Univ. of Illinois Press, 1963.
2. R. Clausius, “On the Application of the Theorem of the Equivalence of
Transformations to Interior Work,” communicated to the Naturforschende
Gesellschaft of Zurich, Jan. 27th, 1862; published in the Viertaljahrschrift of
this Society, vol. vii., p. 48.
3. J. Olivain and J. Goubault-Larrecq, Detecting Subverted Cryptographic Pro-
tocols by Entropy Checking, research report LSV-06-13, Laboratoire Spécifi-
cation et Vérification, June 2006; www.lsv.ens-cachan.fr/Publis/RAPPORTS
_LSV/PDF/rr-lsv-2006-13.pdf.
4. M. Weber et al., “A Toolkit for Detecting and Analyzing Malicious Soft-
ware,” Proc. 18th Ann. Computer Security Applications Conf., IEEE CS Press,
2002, pp. 423–431.

3. R.W. Hamming, Coding and Information Theory, 2nd ed., 7.4

Prentice-Hall, 1986. 2000 2001 2002 2003 2004 2005
4. M. Haahr, “An Introduction to Randomness and Ran-
dom Numbers,” Random.org, June 1999; www.random. 7.3
org/essay.html.
5. A. Stephan, “Improving Proactive Detection of Packed
7.2
Entropy high score

Malware,” Virus Bulletin, 01 Mar. 2006; www.virusbtn.

com/virusbulletin/archive/2006/03/vb200603-packed.

7.1
Robert Lyda is a research engineer at Sparta, where he analyzes
malicious code for government and law enforcement agencies.
In addition to malware trend and technology assessments, he
7.0
provides such agencies with detailed reporting of specific mal-
ware samples using static and dynamic analysis techniques. His
research interests include applying machine-learning mechanisms
for classifying malware samples based on statically observable 6.9
features. He has a BS in computer science from the University of
Maryland, College Park. Contact him at robert.lyda@sparta.com.
6.8
Jim Hamrock is a software engineer with McDonald Bradley, .text .data .rsrc .reloc .rdata .idata CODE DATA .aspack UPX1 UPX2 pec1 pec2
where he is a leading researcher in malware-analysis trends,
applying mathematical and statistical models to study patterns
and trends in large sample collections. His research interests Figure 4. Annual average entropy high scores for each section
include developing algorithms and software analysis tools and type. The technologies’ strengths generally increased over the
reverse engineering of malware samples. He has an MS in
applied mathematics from Johns Hopkins University. Contact study period.
him at jhamrock@mcdonaldbradley.com.

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 45

 Malware

Code Normalization
for Self-Mutating Malware

Next-generation malware will adopt self-mutation to

circumvent current malware detection techniques. The
authors propose a strategy based on code normalization
that reduces different instances of the same malware into a
common form that can enable accurate detection.

DANILO ost of today’s commercial malware-detection tical viewpoint,

BRUSCHI,
LORENZO
MARTIGNONI,
AND MATTIA
MONGA
M tools recognize malware by searching for
peculiar sequences of bytes. Such byte
strings act as the malware’s “fingerprint,”
enabling detection tools to recognize it inside executable
programs, IP packet sequences, email attachments, digi-
Università tal documents, and so on. Thus, these patterns are usually
degli Studi di called malware signatures. Detectors assume that these sig-
Milano natures won’t change during the malware’s lifetime. Ac-
cordingly, if the fingerprint changes (that is, if the
malware code mutates), detection tools can’t recognize it
until the malware-detection team develops a new finger-
print and integrates it into the detector. To defeat signa-
ture-based detection, attackers have introduced
metamorphic malware—that is, a self-mutating malicious
code that changes itself and, consequently, changes its
fingerprint automatically on every execution.1 (Code ob-
fuscation involves transforming a program into a seman-
tically equivalent one that’s more difficult to reverse
engineer. Self-mutation is a particular form of obfusca-
tion in which the obfuscator and the code being obfus-
cated are the same entity.) Although this type of malware
hasn’t yet appeared in the wild, some prototypes have
been implemented (for example, W32/Etap.D, W32/
Zmist.DR, and W32/Dislex), demonstrating these muta-
tion techniques’ feasibility and efficacy against traditional
antivirus software. Recent work also demonstrates that at-
tackers can easily circumvent current commercial virus
scanners by exploiting simple mutation techniques.2,3
Perfect detection of self-mutating malware is an unde-
cidable problem—no algorithm can detect with complete
accuracy all instances of a self-mutating malware.4 Despite
such negative results, we strongly believe that from a prac-
reliable detection is
possible. We base this belief on several considerations,
which we outline in a later section. On the basis of these
observations, and considering a series of advances in mal-
ware detection presented in the literature (see the sidebar),
we developed our own approach for dealing with self-mu-
tating code that uses static analysis to exploit the weak-
nesses of the transformations the self-mutating malware
have adopted. The result is a prototype tool that, in the
cases we’ve considered, can determine the presence of a
known self-mutating malicious code, the guest, within an
innocuous executable program, the host.
Mutation and infection techniques
Executable object mutations occur via various program-
transformation techniques.5–7 Basically, malware mutates
itself and hides its instructions within the host’s benign
program code.
Mutation techniques
A malware can adopt several common strategies to
achieve code mutation. As it applies these transforma-
tions several times randomly, each one introduces further
perturbations locally, to a basic block, as well as globally to
the control-flow graph. When the malware introduces a
fake conditional jump, for example, subsequent transfor-
mations obfuscate the way in which the program com-
putes the predicate, and so on.
Instruction substitution. A sequence of instructions is
associated with a set of alternative instruction sequences
that are semantically equivalent to the original one. The

46 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY
 Malware

Related work in malware-detection techniques

F rédéric Perriot first proposed the idea of leveraging code-
optimization techniques to aid malicious code detection in 2003.1
Building on that work, we show in the main article that the transfor-
mations current malicious codes adopt are weak and can be reverted
to reduce different instances of the same malware into the same
canonical form. We can then use this form as a pattern for detection.
The malware detector Mihai Christodorescu proposes2 is based
on the idea of semantic-aware signatures and leverages static
analysis and decision procedures to identify common malicious
behaviors that are shared among different malware variants but are
generally obfuscated to protect them from standard detection
techniques. Thus, a malware detector can use one signature to
detect a big class of malicious codes that share the same common
behaviors. Our work, instead, focuses on code normalization
because we believe it’s fundamental to identifying equivalent code
fragments generated through self-mutation.
Other authors’ works perform malware normalization via term
rewriting.3 The rewriting system proposed is suited to the rules
used by self-mutating engines and can help normalize different
malware instances generated using instruction substitution and
irrelevant instructions insertion. Our approach doesn’t guarantee
perfect equivalence among different normal forms (that is, dif-
ferent malware instances can still perform the same operation
using different machine instructions), but it can remove unnec-
essary computations and recover the original control-flow graph.
Moreover, our approach is independent of the particular rules for
self-mutation the malware adopts, so we don’t need any
knowledge about the malware to normalize its instances.
Different researchers propose the idea of assessing program
equivalence by comparing control-flow or call graphs. In one
work,4 the similarity measure obtained from comparing the call
graph helps automatically classify malicious code in families; this
classification is coherent with the actual malware naming. In
another,5 researchers measure program-functions similarity by
comparing a fingerprint generated from their control-flow graph
to each other and then using it to identify the same function
within different executables. Unfortunately, we can’t use these
approaches in our context for two reasons:
• The malicious code can be located anywhere, even inside another
procedure, so we should formulate the detection as a subgraph
isomorphism and not as a graph isomorphism (or a simplified in-
stance, such as comparing graphs fingerprints).
• One main, observable difference among different instances of the
same self-mutating malicious code is in the control graph’s struc-
ture; thus, normalization is a fundamental step toward performing
effective control-flow graph matching.
Finally, the idea of generating a fingerprint from the executable
control-flow graph and using it to detect different instances of the
same polymorphic worm is proposed in another work,6 from which
we adopted our labeling technique. Their fingerprinting technique,
however, suffers the latter of the two problems just described.
References
1. F. Periot, “Defeating Polymorphism Through Code Optimization,” Proc.
Virus Bulletin Conf. 2003, Virus Bulletin, 2003, pp. 142–159.
2. M. Christodorescu et al., “Semantics-Aware Malware Detection,” Proc.
2005 IEEE Symp. Security and Privacy, IEEE CS Press, 2005, pp. 32–46.
3. A. Walenstein et al., “Normalizing Metamorphic Malware using Term
Rewriting,” Proc. Int’l Workshop on Source Code Analysis and Manipulation
(SCAM), IEEE CS Press, 2006, pp. 75–84.
4. E. Carrera and G. Erdélyi, “Digital Genome Mapping—Advanced Binary Mal-
ware Analysis,” Proc. Virus Bulletin Conf., Virus Bulletin, 2004, pp. 187–197.
5. H. Flake, “Structural Comparison of Executable Objects,” Proc. Conf. Detec-
tion of Intrusions and Malware & Vulnerability Assessment (DIMVA), IEEE CS
Press, 2004, pp. 161–173.
6. C. Kruegel et al., “Polymorphic Worm Detection using Structural Infor-
mation of Executables,” Proc. Int’l Symp. Recent Advances in Intrusion Detec-
tion, Springer, 2005, pp. 207–226.

malware can replace every occurrence of the original se-
quence with an arbitrary element from this set.
Instruction permutation. Independent instructions—
that is, those whose computations don’t depend on pre-
vious instructions’ results—can be arbitrarily permuted
without altering the program’s semantics. For example,
the malware can execute the three statements a = b * c,
d = b + e, and c = b & c in any order, provided that the
use of the c variable precedes its new definition.
Garbage insertion. This is also known as dead-code in-
sertion, and involves the malware inserting, at a particular
program point, a set of valid instructions that don’t alter
its expected behavior. Given the following sequence of
instructions a = b / d, b = a * 2, for example, the
malware can insert any instruction that modifies b be-
tween the first and the second instruction. Moreover, in-
structions that reassign any other variables without really
changing their value can be inserted at any point of the
program (for example, a = a + 0, b = b * 1, ...).
Variable substitutions. The malware can replace a vari-
able (register or memory address) with another variable
belonging to a set of valid candidates preserving the pro-
gram’s behavior.
Control-flow alteration. Here, the malware alters the
order of the instructions as well as the program’s structure
by introducing useless conditional and unconditional

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 47

 Malware
Alleged infected program
Code interpretation
Code normalization
Expression propagation
Dead-code elimination
Expression simplification
Indirections resolution
Control-flow normalization
Normalized code
Known malicious code
Code comparison
Match archetype?
Figure 1. Overview of the detection process. Starting with a suspicious
program, we translate it into the normal form, normalize it, and then
compare the normalized version with known malicious programs.
branch instructions such that at runtime, the order in
which the program executes single instructions isn’t
modified. Furthermore, the malware can translate direct
jumps and function calls into indirect ones whose desti-
nation addresses are camouflaged through other instruc-
tions in order to prevent an accurate reconstruction of the
control flow.
Infection techniques
To camouflage the link between the benign host and the
malicious guest, the malware tangles each one’s instruc-
tions together by exploiting smart techniques referred to
as entry-point obfuscation (see http://www3.ca.com/
securityadvisor/glossary.aspx). Once the malware
achieves a seamless integration, the host invokes the new
guest code in a way very similar to how it invokes other
portions of its own code. Moreover, the host will con-
tinue to work exactly as it did before the infection.
The malware can adopt different techniques—
which require minimal effort to implement—to
achieve this goal.
Cavity insertion. Generally, executables contain several
48 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
portions that aren’t used to store data or code (compilers
can introduce them to align code and data structure). The
malware identifies these “cavities” and uses them to insert
small pieces of malicious code that the host will execute
after minor modifications of its code.
Jump-table manipulation. In a compiled program,
high-level control-flow transfer constructs such as
switch are implemented using jump tables to redirect
the execution to the appropriate location according to
the table’s contents and the value that the control variable
assumes. The malware can modify entries of such tables
to get the host to redirect the execution anywhere.
Data-segment expansion. To create the required space
inside the host code’s address space, malware can expand
some of the host segments as needed. Not all segments
are suited for expansion because that would require relo-
cating most of the code. Other segments, such as the one
storing uninitialized data, seem to be more appropriate
because their expansion allows the malware to insert ma-
licious code without requiring further modification of
the host code.
Proposed detection strategy
To be effective, malware mutations must be automatic
and efficient; otherwise, their mutation computations
would be too difficult to hide. More precisely,8 a self-
mutating malware must be able to analyze its own body
and extract from it all the information needed to mutate
itself into the next generation, which in turn must be able
to perform the same process, and so forth. Because muta-
tions occur directly on machine code, and the mutation
engine is embedded directly into the malicious code it-
self, the applicable transformations must, in most cases,
be rather trivial. Consequently, we can iteratively reverse
the mutation process until we obtain an archetype (that is,
the original and unmutated version of the program from
which the malware derives other instances). Experimen-
tal observations show that self-mutating programs are ba-
sically highly unoptimized code, containing a lot of
redundant and useless instructions.
Our detection process is thus divided into three steps:
code interpretation, code normalization, and code comparison.
Figure 1 illustrates the entire detection process: the detec-
tor’s input is an executable program that hosts a known
malicious code. The code interpreter then transforms the
program into an intermediate form, which is then nor-
malized. Finally, the code comparator analyzes the nor-
malized form to identify possible matches of the known
malicious code within the normalized program.
Code interpretation
To ease the manipulation of object code, our detector
uses a high-level representation of machine instructions
 Malware

to express every opcode’s operational semantics, as well as Table 1. An example of code interpretation.
the registers and memory addresses involved. Code inter-
pretation considerably simplifies the subsequent sub- MACHINE INSTRUCTION INTERPRETED INSTRUCTION
processes because normalization and comparisons will
target a language with a very limited set of features and pop %eax r10 = [r11]
instructions. In fact, the instructions composing the lan- r11 = r11 + 4
guages are just assignments, function calls, jumps (condi- lea %edi, [%ebp] r06 = r12
tional and unconditional), and function returns. The dec %ebx tmp = r08
instruction operands can be only registers, memory ad- r08 = r08 - 1
dresses, and constants. NF = r08@[31:31]
Table 1 shows a simple example, reduced from the ZF = [r08 = 0?1:0]
original due to space constraints. In the table, the nota- CF = (~(tmp@[31:31])...
tion [r10] denotes the content of the memory whose ...
effective address is in the register r10, and the notation
r10@[31:31] denotes a slice of bits of the register r10,
composed by the register’s bit. Note that even the simple Table 2. A scenario generating a high-level expression.
dec instruction conceals a complex semantics: its argu-
ment is decremented by one, and the instruction, or the ORIGINAL EXPRESSION RECONSTRUCTED EXPRESSION
subtraction, produces an update of six control flags ac- r10 = [r11] r10 = [r11]
cording to the result. r10 = r10 | r12 r10 = [r11] | r12
[r11] = [r11] & r12
Code normalization [r11] = ~[r11]
The code normalizer’s goal is to transform a program [r11] = [r11] & r10 [r11] = (~([r11] & r12)) &
into a canonical form that’s simpler in terms of structure ([r11] | r12)
or syntax, while preserving the original semantics. We
observed that most of the transformations a malware uses
to dissimulate its presence lead to underoptimized ver- no more than one or two operands. Propagation carries
sions of the archetype. The mutated versions grow be- forward values assigned or computed by intermediate
cause they’re stuffed with irrelevant computations instructions. This lets us generate higher-level expres-
whose presence only has the goal of avoiding recogni- sions (with more than two operands) and eliminate all
tion. Normalization thus aims to transform the code intermediate temporary variables that the malware used
into a more compact form by reducing the number of to implement high-level expressions. The code frag-
useless instructions, as well as the number of indirect ment in Table 2 shows a simple scenario in which,
paths. We can consequently view normalization as an thanks to propagation, our detector generates a higher-
optimization of the malicious code aimed at simplifying level expression.
the code structure.
The normalization process consists of a set of transfor- Dead-code elimination. Dead instructions are those
mations that compilers adopt to optimize the code and whose results the program never uses. We remove them
improve its size.9–11 They all rely on the information col- from a program because they don’t contribute to the
lected during a static analysis phase (control-flow and computation. In Table 2, the first instruction, after
data-flow analysis), which we perform on the code at the propagation, is completely useless because the inter-
beginning of the normalization process. The more accu- mediate result has been propagated directly into the
rate the static analysis, the higher the chances of applying next instruction.
these transformations. We also classify assignments as dead instructions when
Given that the malicious code can be anywhere in- they define a variable but don’t change its value (for ex-
side the host program, we perform the normalization ample, r10 = r10 + 0).
on the whole program, letting the normalization
process also target the malicious guest. As Figure 1 Expression simplification. Most of the expressions
shows, all transformations are repeated iteratively be- contain arithmetical or logical operators, so they can
cause they depend on each other; normalization will sometimes be simplified automatically according to ordi-
stop when we can no longer apply any of these transfor- nary algebraic rules. When simplification isn’t possible,
mations to the code. our tool can reorder variables and constants to enable fur-
ther simplification after propagation.
Expression propagation. The Intel IA-32 assembly in- Simplification becomes very useful when applied to
structions denote simple expressions that generally have expressions representing branch conditions and memory

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 49

 Malware

1 xor %ebx,%ebx 1 r11 := r11 ^ r11 1 r11 := 0 1 r11 := 0

2 mov $0x1000400c,%eax 2 r10 := 0x10004014 2 r10 := 0x10004014 2 r10 := 0x10004014
3 mov %eax,0x10004014 3 [0x1000400c] := r10 3 [0x1000400c] := 0x10004014 3 [0x1000400c] := 0x10004014
4 add %ebx,%eax 4 r10 := r10 + r11 4 r10 := 0x10004014 + 0 4 r10 := 0x10004014 + 0
5 test %ebx,%ebx 5 tmp = r11 - r11 5 tmp = 0 - 0 5 tmp = 0 - 0
6 jne <T> 6 ZF = [tmp = 0?1:0] 6 ZF = [0 = 0?1:0] 6 ZF = 1
7 push %ebx 7 jump (ZF = 1) T 7 jump (ZF = 1) T 7 jump (ZF = 1) T
8 mov $0x0,%ebx 8 [r15] := r11 8 [r15] := 0 8 [r15] := 0
T: 9 r15 := r15 - 4 9 r15 := r15 - 4 9 r15 := r15 - 4
9 jmp *%eax 10 r11 := 0 10 r11 := 0 10 r11 := 0
10 leave T: T: T:
11 ret 11 jump r10 11 jump 0x10004014 + 0 11 jump 0x10004014
12 nop 12 r15 := r16 12 r15 := r16 12 r15 := r16
13 r16 := m[r15] 13 r16 := m[r16] 13 r16 := m[r16]
14 r15 := r15 + 4 14 r15 := r15 + 4 14 r15 := r15 + 4
15 return 15 return 15 return
(a) (b) (c) (d)

Figure 2. Malicious code and normalization. (a) A small fragment of malicious code and (b), (c), and (d) the corresponding
steps of the transformation into the normalized form. To keep the figure compact, we simplified the instruction’s semantics
by removing irrelevant control flags updates. Instructions that are struck through are considered dead.

addresses because it lets us identify tautological condi-
tions as well as constant memory addresses somehow
camouflaged through more complex expressions.
Indirection resolution. Assembly code is generally
rich with indirect memory accesses and control trans-
fers; for example, during compilation, switch-like
statements are translated into jumps through an indirect
jump table. When we encounter indirect control trans-
fers during code interpretation, the currently available
information isn’t sufficient for us to estimate the set of
admissible jump targets. During code normalization,
however, we can “guess” some of the targets based on
information collected through static analysis and subse-
quently elaborated during the transformations. Once
identified, these new code segments are ready for analy-
sis, we invoke the code interpretation on this code, and
the normalizer then processes the output (purple line in
Figure 1).
Control-flow normalization. A malware can signifi-
cantly twist a program’s control flow by inserting fake
conditional and unconditional jumps. A twisted control
flow can affect the quality of the entire normalization
process because it can limit other transformations’ effec-
tiveness. At the same time, other transformations are es-
sential for improving the quality of the control-flow
graph’s normalization (for example, algebraic simplifica-
tions and expression propagation). We can perform dif-
ferent types of normalizations on the control flow; for
example, with code straightening, a straight sequence of in-
structions can replace a chain of unconditional jump in-
structions. During spurious path pruning, we can prune
dead paths arising from fake conditional jump instruc-
tions from the control flow to create new opportunities
for transformation.
An example. To better explain when and how we can
apply the transformations composing the normalization
process, we present a simple example. Figure 2 shows a
small fragment of malicious code as well as the code ob-
tained during the normalization process’s intermediate
iterations. The code in Figure 2a is unnecessarily com-
plex, and we can translate it into a simpler form: the code
contains a tautological conditional branch in addition to
an undirected jump, whose target address we can evalu-
ate statically.
Figure 2b shows the output of the normalization
process’s first step, which consists of translating the code
into its corresponding intermediate form. We apply
transformations such as algebraic simplifications and ex-
pression propagation directly to this new form; note that
we can evaluate the value of some expressions statically
and propagate these values into other expressions that use
them. The instruction at line 4 in Figure 2c, for example,
turns out to be completely useless because it doesn’t alter
the original value computed by the instruction at line 2.
Moreover, through propagation, this constant value is
also copied inside the expression that represents the jump
target address (line 11), thus allowing us to translate the
indirect jump into a direct one. In Figure 2d, which rep-
resents the normal form, we can see that the conditional
jump (line 7) has been removed because the condition
turns out to be always true; thus we can remove the fall-
back path from the program. Instructions that are struck
through are considered dead.
Code comparison
Unfortunately, we can’t expect normalization to reduce
different instances of a malicious code to the same normal
form—not every transformation is statically reversible
(for example, when the order of instruction is per-
mutable, or when the malware performs the same opera-

50 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007

 Malware

tion executing different instructions that are transformed

into a different intermediate form). Thus, a bytewise
comparison will likely lead to false negatives. During our
experiments, we tried to classify the typologies of differ-
ences found in the normalized instances and discovered
that they were all local to basic blocks. In other words,
normalized instances of malicious code often share the
same control flow.
To elicit the similarities, therefore, we decided to
represent the malicious code and the alleged normal-
ized host program through their interprocedural control-
flow graphs, which are all procedures’ control-flow
graphs combined. Under this assumption, we can for-
mulate the search for malicious code as a subgraph iso-
morphism decision problem: given two graphs G1 and
G2, is G1 isomorphic to a subgraph of G2? (Even
though subgraph isomorphism is in general NP-com-
plete,12 with our particular problem, control-flow
graphs are very sparse, and finding a solution is usually
tractable.) Figure 3 shows the two graphs just men-
tioned: Figure 3a models the malicious code, whereas
Figure 3b matches the suspicious program (nodes high-
lighted are those that match).
Comparison through interprocedural control-flow
(a) (b)
graphs lets us abstract the information from local to
basic blocks. This is beneficial in that we’re throwing
away every possible source of difference, but it could be Figure 3. Two control flow graphs. We present (a) a malicious code
a disadvantage if we consider that the information we’re M and (b) a normalized program PN. The nodes highlighted in
losing can help identify pieces of code that share the purple are those from PN that matching ones in M.
same structure but have different behaviors. Thus,
we’ve augmented these graphs by labeling both nodes
and edges: we labeled nodes according to the instruc- Table 3. Instructions and flow transitions classes.
tion properties belonging to them and edges according
to the type of flow relations among the nodes they con- INSTRUCTIONS CLASSES FLOW TRANSITIONS CLASSES
nect. A similar labeling method is proposed else-
where.13 We group instructions with similar semantics Integer arithmetic One-way
into classes and assign a number (label) to each node that Float arithmetic Two-way
represents all the classes involved in the basic block. Logic Two-way (fallback or false)
Table 3 shows the classes in which we’ve grouped in- Comparison N-way (computed targets of indirect jumps
structions and flow transitions. We also represent calls to or calls)
shared library functions with the same notation: the Function call
caller node is connected to the function that’s repre- Indirect function call
sented with just one node and labeled with a hash calcu- Branch
lated on the function name. Jump
Indirect jump
Prototype implementation Function return
To experimentally verify our approach, in terms of both
correctness and efficiency, we developed a prototype.
We built the code normalization module on top of gine to undo the previously described mutations. Using
Boomerang (http://boomerang.sourceforge.net), an the information collected with the analysis, our tool de-
open source decompiler that reconstructs high-level cides which set of transformations to apply to a piece of
code by analyzing binary executables. Boomerang per- code based on control- and data-flow analysis results.
forms the data- and control-flow analysis directly on an The analysis framework can also accommodate the res-
intermediate form14 automatically generated from ma- olution of indirections and performs jump- and call-
chine code. We adapted it to our needs and used the en- table analysis15 (further details are available elsewhere16).

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 51

 Malware
After the prototype has normalized the code, it builds
a labeled control-flow graph of the resulting code, along
with the malware’s control-flow graph, and we give the
graph in input to a subgraph isomorphism algorithm in
order to perform the detection. The prototype of our
tool performs subgraph matching, leveraging the VF2
algorithm from the VFLIB library (http://amalfi.dis.
unina.it/graph/db/vflib-2.0/).17
Experimental results
To evaluate the presented approach, we performed a set
of independent experimental tests to assess the normal-
ization procedure’s quality and the code comparator’s
precision. The results demonstrate how effective our ap-
proach is but also highlight that we still need to do a lot of
work to build a code normalizer that we can use with
real-world executables.
Code normalization evaluation
We evaluated the code normalization’s effectiveness by
analyzing two different self-mutating malicious pro-
grams: W32/Etap.D (also known as Metaphor) and
W32/Dislex. The former is considered one of the most
interesting self-mutating malicious codes and evolves
through five steps. The malware
1. disassembles the current payload;
2. compresses the payload according to a set of prede-
fined rules to avoid size explosion;
3. mutates the payload by introducing fake conditional
and unconditional branches;
4. expands the payload by applying step 2’s rules in re-
verse; and
5. assembles the mutated payload.
W32/Dislex is slightly simpler because it just inserts use-
less code and permutes the payload by inserting fake con-
trol-flow transitions.
We collected different instances of the malicious pro-
grams by executing them in a virtual environment and
forcing them to infect a set of predefined test programs.
We repeated this step several times consecutively in order
to infect new programs, using a newly generated malware
instance every time. We collected 115 different samples
of W32/Etap.D and 63 of W32/Dislex. We manually
identified each malware’s starting point in the various
hosts—for W32/Etap.d, we chose an address stored at a
fixed location in the executable import address table,
whereas for W32/Dislex we chose the image start ad-
dress—to focus the analysis only on the malicious pay-
load. (In both cases, the code fragment analyzed seems to
belong to a decryption routine that decrypts the real ma-
licious payload.) We then compared the code before ap-
plying normalization and after.
For W32/Etap.d, we noticed that, in some cases,
52 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
there was a correspondence between the archetype and
the instance even before normalization. Given that the
type of transformations applied during self-mutation
are randomly chosen, we believe that the malware ap-
plied very weak transformations while generating
those instances. After normalization, we noticed that
all the samples matched the chosen archetype. We also
observed an average reduction in the code size of about
57 percent.
Further experimentation with W32/Dislex con-
firmed these results. We noticed that before normaliza-
tion, some graphs corresponded to each other, but none
matched the archetypes; a deeper investigation revealed
that the instances generated during the same infection
shared the same payload. After normalization, we no-
ticed that the control-flow graphs were perfectly iso-
morphic if we didn’t consider node labels. Through
labeling, we identified four different types of archetypes
that differed only in the labels of one or two nodes. In
some cases, the nodes ended with a jump absent in the
others; during normalization the tool couldn’t remove
these extra jumps because they were located exactly at
the end of a real basic block. Overall, thanks to normal-
ization, we observed an average reduction in the graph
size of roughly 65 percent and the elimination of
approximately half the payload instructions.
In our experiments, we have applied normalization
directly to the malicious code. In the real world, however,
the malware is tangled into the host code—we would
perform its normalization implicitly when normalizing
the entire host code. Unfortunately, our prototype isn’t
mature enough to handle big executables and, although
we believe normalization will be quite effective on the
executable that hosts the malicious instructions, we were
unable to make this assessment. In fact, two problems
might reduce normalization’s effectiveness:
• Our tool might not be able to explore the benign host
code completely, and the code that invokes the mali-
cious guest lies in the unexplored region.
• Our tool could explore the benign host code com-
pletely, but couldn’t resolve the links with the malicious
code region.
Heuristics to maximize code exploration already
exist, and we can adopt them to overcome the first prob-
lem (Boomerang already handles common cases17). The
second problem is less worrying because normalization
appears to be rather effective in reconstructing an obfus-
cated control flow, and malware uses the same techniques
to hide malicious code among host instructions.
Code comparison evaluation
We’ve evaluated the code comparator via an independent
test to measure its precision (more details are available

elsewhere18). First, we collected a huge set of system bi-
nary executables and constructed their augmented inter-
procedural control-flow graph. We then split this graph
in order to construct a graph for each program function.
We used the functions identified to simulate malicious
code and searched within all the sample set’s programs;
we threw away graphs with fewer than five nodes because
they’re too small to unambiguously characterize a partic-
ular code fragment. We then divided the code compara-
tor output into three sets:
• equivalent graphs generated from equivalent functions
(two functions were equivalent if the hashes computed
on their opcodes matched);
• equivalent graphs generated from functions with dif-
ferent hashes; and
• different graphs generated from functions with differ-
ent hashes.
We then compared a small number of random elements
of the last two sets to verify the presence of false posi-
tives and false negatives. Table 4 shows the results ob-
tained through this manual inspection. Besides a bug
found in the prototype, manual inspection highlighted
that, in most cases, the compared functions were se-
mantically equivalent even when the hashes didn’t
match (we suspect that the same function was compiled
with slightly different options). False positives arose
only when we compared very small graphs (fewer than
seven nodes). Manual inspection also revealed that all
graphs reported to be different were generated from dif-
ferent functions.
D espite theoretical studies demonstrating that it’s
possible in principle to build undetectable mali-
cious code, we’ve demonstrated that the techniques
malicious code writers currently adopt to achieve per-
fect mutation don’t let them get too close to the theo-
retical limit.
We believe that the experimental results we obtained
regarding our normalization process demonstrates that it
adequately treats techniques that self-mutating malware
currently adopts. Unfortunately, we expect that in the
near future, such transformations will be replaced with
more sophisticated ones, which could seriously under-
mine the effectiveness of static analysis and, consequently,
our proposed approach as well. These transformations
could include the use of function calls and returns to
camouflage intrafunction control-flow transitions; the
introduction of opaque predicates; the introduction of
junk code containing useless memory references that will
create spurious data dependencies; and the adoption of
antidisassembling techniques.
Another important issue we must address in the future
Malware
Table 4. Results from manual evaluation of a
random subset of the code comparator results.
POSITIVE RESULTS (EQUIVALENT GRAPHS) # %
Equivalent code 35 70
Equivalent code (negligible differences) 9 18
Different code (small number of nodes) 3 6
Unknown (too big to compare by hand) 1 2
Bugs 2 4
NEGATIVE RESULTS (DIFFERENT GRAPHS) # %
Different code 50 100
is reducing the resources requested for the analysis. The
static analysis we perform on the malicious code is in
general quite expensive, so we believe that it’s necessary
to perform the analysis on the smallest portion of code
possible, but this means that in the future, we must be able
to identify which part of the code to focus on.
References
1. P. Ször and P. Ferrie, “Hunting for Metamorphic,” Proc.
Virus Bulletin Conf., Virus Bulletin, 2001, pp. 123–144.
2. M. Christodorescu and S. Jha, “Testing Malware Detec-
tors,” Proc. 2004 ACM SIGSOFT Int’l Symp. Software
Testing and Analysis (ISSTA 04), ACM Press, 2004, pp.
34–44.
3. M. Christodorescu and S. Jha, “Static Analysis of Exe-
cutables to Detect Malicious Patterns,” Proc. Usenix Secu-
rity Symposium, Usenix Assoc., 2003, pp. 169–186.
4. D.M. Chess and S.R. White, “An Undetectable
Computer Virus,” Proc. Virus Bulletin Conf., Virus Bul-
letin, 2000; www.research.ibm.com/antivirus/SciPapers/
VB2000DC.htm.
5. F.B. Cohen, A Short Course on Computer Viruses, 2nd ed.,
Wiley, 1994.
6. C. Collberg, C. Thomborson, and D. Low, A Taxon-
omy of Obfuscating Transformations, tech. report 148,
Dept. of Computer Science, Univ. of Auckland, July
1997.
7. P. Ször, The Art of Computer Virus Research and Defense,
Addison-Wesley, 2005.
8. A. Lakhotia, A. Kapoor, and E.U. Kumar, “Are Meta-
morphic Viruses Really Invincible?” Virus Bulletin, Dec.
2004, pp. 5–7.
9. S.K. Debray et al., “Compiler Techniques for Code
Compaction,” ACM Trans. Programming Languages and
Systems, vol. 22, no. 2, 2000, pp. 378–415.
10. S.S. Muchnick, Advanced Compiler Design and Implemen-
tation, Morgan Kaufmann, 1997.
11. A.V. Aho, R. Sethi, and J.D. Ullman, Compilers: Principles,
Techniques and Tools, Addison-Wesley, 1986.
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 53
 Malware

12. J.R. Ullman, “An Algorithm for Subgraph Isomor-
phism,” J. ACM, vol. 23, no. 1, 1976, pp. 31–42.
13. C. Kruegel et al., “Polymorphic Worm Detection using
Structural Information of Executables,” Proc. Int’l Symp.
Recent Advances in Intrusion Detection, Springer, 2005, pp.
207–226.
14. C. Cifuentes and S. Sendall, “Specifying the Semantics
of Machine Instructions,” Proc. 6th Int’l Workshop on Pro-
gram Comprehension (IWPC 98), IEEE CS Press, 1998,
pp. 126–133.
15. C. Cifuentes and M.V. Emmerik, “Recovery of Jump
Table Case Statements from Binary Code,” Proc. 7th Int’l
Workshop on Program Comprehension, IEEE CS Press, 2001,
pp. 171–188.
16. D. Bruschi, L. Martignoni, and M. Monga, “Using Code
Normalization for Fighting Self-Mutating Malware,”
Proc. Int’l Symp. Secure Software Engineering, IEEE CS
Press, 2006, pp. 37–44.
17. L.P. Cordella et al., “A (Sub)graph Isomorphism Algo-
rithm for Matching Large Graphs,” IEEE Trans. Pattern
Analysis and Machine Intelligence, vol. 26, no. 10, 2004,
pp. 1367–1372.
18. D. Bruschi, L. Martignoni, and M. Monga, “Detecting
Self-Mutating Malware Using Control Flow Graph
Matching,” Proc. Conf. Detection of Intrusions and Malware
Sign Up Today
& Vulnerability Assessment (DIMVA), Springer, 2005, pp.
129–143.
Danilo Bruschi is a professor of computer sciences at Università
degli Studi di Milano, Italy, where he is also director of the Mas-
ter Program in ICT Security, director of the Laboratory for Secu-
rity (LASER), and teaches computer and network security and
operating systems. His main research interests include computer
and network security, reliability, and survivability, computer
forensics, social implications, and privacy. Bruschi has a PhD in
computer sciences from the Università degli Studi di Milano.
Contact him at bruschi@dico.unimi.it.
Lorenzo Martignoni is currently enrolled in the PhD program in
computer science at Università degli Studi di Milano, Italy. His
research interests include computer security and the analysis of
malicious code and computer forensics in particular. Martignoni
has an MS in computer sciences from Università degli Studi di
Milano-Bicocca, Italy. Contact him at martign@dico.unimi.it.
Mattia Monga is an assistant professor in the Department of
Computer Science and Communication at the Università degli
Studi di Milano. His research activities are in software engi-
neering and security. Monga has a PhD in computer and
automation engineering from Politecnico di Milano, Italy. He is
a member of the IEEE Computer Society and is on the steering
committee of CLUSIT, an Italian association promoting aware-
ness, continuous education, and information sharing about dig-
ital security. Contact him at monga@dico.unimi.it; http://
homes.dico.unimi.it/~monga/.

For the
IEEE
Computer Society
Digital Library
E-Mail Newsletter
■ Monthly updates highlight the latest additions to the digital library
from all 23 peer-reviewed Computer Society periodicals.

■ New links access recent Computer Society conference publications.

■ Sponsors offer readers special deals on products and events.

Available for FREE to members, students, and computing professionals.

Visit http://www.computer.org/services/csdl_subscribe

54 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007


Trust Negotiation
in Identity Management
Most organizations require the verification of personal
information before providing services, and the privacy of such
information is of growing concern. The authors show how
federated identity management systems can better protect
users’ information when integrated with trust negotiation.
n today’s increasingly competitive business envi-
I ronment, more and more leading organizations are
building Web-based infrastructures to gain the
strategic advantages of collaborative networking.
However, to facilitate collaboration and fully exploit
such infrastructures, organizations must identify each
user in the collaborative network as well as the resources
each user is authorized to access. User identification and
access control must be carried out so as to maximize
user convenience and privacy without increasing orga-
nizations’ operational costs. A federation can serve as the
basic context for determining suitable solutions to this
issue. A federation is a set of organizations that establish
trust relationships with respect to the identity informa-
tion—the federated identity information—that is consid-
ered valid. A federated identity management system
(IdM) provides a group of organizations that collaborate
with mechanisms for managing and gaining access to
user identity information and other resources across or-
ganizational boundaries.
IdM systems involve at least two types of entities: identity
providers and service providers. An IdP manages user authenti-
cation and user-identity-relevant information. A service
provider (SP) offers services to users who satisfy the policy
requirements associated with these services. It specifies and
enforces the access-control policies for the resources it of-
fers. An organization in a federation can act as both an IdP
and an SP. In most IdM systems (see the “Initiatives and sys-
tems” sidebar), IdPs authenticate users using single-sign-
on technology. With SSO, users can log on with the same
username and password for seamless access to federated ser-
vices within one or multiple organizations. Federated iden-
tity includes not only users’ login names, but also user
PUBLISHED BY THE IEEE COMPUTER SOCIETY
Identity Management
properties, or user identity attributes (user
attributes, for short). Thus, authorizations
specified for a given resource are no longer expressed in
terms of user login IDs but in terms of requirements and
conditions against user properties.
One challenge with current IdM systems is distributing
ABHILASHA
BHARGAV-
S PANTZEL,
ANNA C.
the IdPs’ functionality among IdPs and SPs (in this article, SQUICCIARINI,
we don’t differentiate between SPs and IdPs in a federa- AND E LISA
tion). We need a secure and privacy-preserving mecha- BERTINO
nism for retrieving the user attributes from different SPs. Purdue
The IdM system must provide only the user information University
that is needed to satisfy the requesting SPs’ access-control
policies. In this regard, users have differentiated privacy
preferences for various types of personal information.1 For
example, users might agree to share demographic informa-
tion but not credit-card or health information. Such re-
quirements call for a flexible and selective approach to
sharing user attributes in federations. A system could
achieve selective release of identity by supporting multiple
federated digital identities. For example, a user could have
a business identity and a personal identity, and their corre-
sponding profiles would have associated privacy prefer-
ences. Such an approach, however, contradicts the main
aim of federated identity solutions—that is, minimizing
the management of multiple profiles by the user.
One way to achieve such flexibility and fine-grained
access is to enhance IdM technology with automated
trust-negotiation (ATN) techniques.2 Trust negotiation
is an emerging access-control approach that aims to es-
tablish trust between negotiating parties online through
bilateral credential disclosure. Such a negotiation aims to
establish a trust level sufficient to release sensitive re-
sources, which can be either data or services.
■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY 55
 Identity Management

Initiatives and systems

L iberty Alliance and WS-Federation are two emerging standards
for identity federation in the corporate world. Because these
projects are similar, we only describe the former.
Liberty Alliance (www.projectliberty.org) is based on Security
Assertion Markup Language (SAML) and provides open
standards for single sign-on with decentralized authentication.
SSO lets users sign on once at a Liberty-enabled site and remain
signed on when navigating to other Liberty-enabled sites. This
group of Liberty-enabled sites belongs to a circle of trust—that
is, a federation of SPs and IdPs based on the Liberty architecture.
The IdP is a Liberty-enabled entity that creates, maintains, and
manages user identity information and provides SPs with this
information. Similarly, the federated attribute management and
trust-negotiation (FAMTN) framework builds on an SSO and
provides a flexible decentralized trust management system for
registered users.
According to the Liberty Alliance framework, a federation might
include multiple IdPs, which could also be SPs. Basically, in a given
Liberty circle of trust, multiple IdPs can share a user’s information.
These IdPs establish trust relationships and access policies a priori
while forming the circle of trust. The Liberty protocols don’t
dictate the underlying semantics and related protocols. Truly de-
centralized identity management requires a more automatic meth-
odology for federating user information among IdPs. The FAMTN
framework doesn’t distinguish SPs from IdPs. Each SP in the fed-
eration can act as an IdP. SPs exchange information through
automatic trust negotiation (ATN), according to an on-demand
dynamic protocol.
The Shibboleth (http://shibboleth.internet2.edu) initiative
originated in academia and is similar to the Liberty Alliance in
that it aims to facilitate resource sharing between research and
academic institutions. It extends the federated identity infor-
mation concept to federated user attributes. When a user at an
institution tries to use a resource at another, Shibboleth sends
attributes about the user to the remote institution, rather than
making the user log in to that institution. The receiver can check
whether the attributes satisfy the SP’s policy. The Shibboleth IdP
accounts for all user attributes and user privacy preferences when
giving information to other SPs. The FAMTN approach differs
from Shibboleth in that it doesn’t rely on a central IdP for all user
attributes. Rather, user attributes are distributed among the fed-
eration SPs, each of which can act as an IdP. The ability to
negotiate with different SPs adds flexibility to how users can de-
fine different privacy preferences with respect to federation
members. Shibboleth requires trust agreements to define the
population, retention, and use of attributes, thus making it dif-
ficult for external users (who aren’t affiliated with the federation)
to carry on ad hoc negotiations for the various services offered. In
other words, unlike our framework, Shibboleth isn’t open to
external users.
Researchers have developed several systems and prototypes
for trust negotiations in Web-based applications. TrustBuilder,1
one of the most significant proposals, provides a set of nego-
tiation protocols that define the message ordering and the type
of information the messages will contain, as well as strategies for
controlling the messages’ exact content. It defines various stra-

In this article, we discuss how to integrate federated
IdM with trust-negotiation techniques. More specifi-
cally, we discuss how to implement trust negotiation be-
tween SPs in a federation, and between users and SPs.
This is, to the best of our knowledge, the first attempt to
integrate a federated IdM system with a trust-negotiation
system. A key aspect of the resulting framework—feder-
ated attribute management and trust negotiation (FAMTN)—
is that a user doesn’t have to provide a federated attribute
(that is, attributes the user is willing to share in a federa-
tion) more than once to a given federation. Internal users
of FAMTN systems can perform negotiations by ex-
ploiting their SSO ID without having to repeat identity
verification. Further, a FAMTN system supports tempo-
rary SSO, so external users can perform negotiations with
the federation using the federated framework to reduce
the amount of identity information they need to provide.
Comparison of IdM
and ATN systems
The trust-negotiation paradigm has several similarities to
federated IdM. Both aim to better handle users’ sensitive
information; however, trust negotiation ultimately aims
to handle introductions between strangers, whereas IdM
systems are typically for closed environments.
ATN systems and IdM systems also differ in several
important ways, as Table 1 shows. Importantly, we based
our analysis on the IdM and ATN models as they were
originally designed. Researchers have proposed varia-
tions to both approaches in the past few years, which
make the evaluation results slightly different.
Open versus closed environment
ATN techniques,3 developed for use in open systems,
provide protocols for introducing strangers to each other.
They might be useful for the initial trust-establishment
process between users and IdPs or to automatically man-
age introductions between different federation groups.
Credential and identity
attribute management
In a typical ATN system, the user is the IdP. ATN is a
user-centric system in which a client stores credentials
and provides them on behalf of a user through negotia-

56 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007

 Identity Management

tegies to let strangers establish trust by exchanging digital cre-
dentials and using access-control policies that specify the combi-
nations of credentials a stranger must disclose to gain access to
each local service or credential. Marianne Winslett and her col-
leagues2 developed Unipro, a unified scheme to model resource
protection, including policies. It represents one of the most sig-
nificant proposals in the negotiation research area, and most sig-
nificantly influenced our work. However, Unipro doesn’t support
privacy policies, nor does it define an ad hoc policy language.
Kent Seamons and his colleagues3 explored the issue of sup-
porting sensitive policies, obtained by introducing hierarchies in
policy definitions. They also addressed privacy issues in trust
negotiation.4 However, their approach doesn’t provide a compre-
hensive solution to such problems because it only deals with pro-
tecting sensitive policies, achieved by dynamically modifying
policies during a negotiation.
William Winsborough and Ninghui Li5 introduced a role-based
trust-management language that they use to map entities to roles
based on the properties described in their credentials. They also
developed an algorithm to locate and retrieve credentials that
aren’t locally available. This credential chain discovery is an
important aspect of trust negotiation because assuming the cre-
dentials to be locally stored is too strong an assumption for decen-
tralized collaborative environments.
We based our framework on Trust-␺,6 a trust-negotiation
system for peer-to-peer environments. Trust-c is complemented by
an ad hoc XML based language, ␺-TNL, for encoding negotiation
policies, digital credentials, and security-related information. A
main difference between Trust-␺ and our work is that FAMTN’s
negotiation process is much more articulated and can involve third
parties in addition to the two parties initiating the negotiation.
Thus, FAMTN is characterized by multiparty negotiations, as
opposed to Trust-␺’s two-party negotiations.
Having been widely studied in theory, ATN systems are now
ready for use in real applications. TrustBuilder is an example of an
actual system for support of trust negotiations. Current Web
services only provide basic negotiation capabilities. The full
potential of trust negotiations will be achieved when the practical
limitations related with public-key infrastructures are overcome.
References
1. T. Yu, M. Winslett, and K.E. Seamons, “Supporting Structured Credentials
and Sensitive Policies through Interoperable Strategies for Automated Trust
Negotiation,” ACM Trans. Information and System Security, vol. 6, no. 1,
2003, ACM Press, pp. 1–42.
2. T. Yu and M. Winslett, “A Unified Scheme for Resource Protection in Auto-
mated Trust Negotiation,” Proc. IEEE Symp. Security and Privacy, IEEE CS
Press, 2003, pp. 110–123.
3. K.E. Seamons, M. Winslett, and T. Yu, “Limiting the Disclosure of Access
Control Policies during Automated Trust Negotiation,” Proc. Network and
Distributed System Security Symp., Internet Soc., 2001.
4. K.E. Seamons, M. Winslett, and T. Yu, “Protecting Privacy During On Line
Trust Negotiation, Proc. 2nd Workshop Privacy Enhancing Technologies,
Springer Berlin, 2002, pp. 129–143.
5. W.H. Winsborough and N. Li, “Protecting Sensitive Attributes in Automated
Trust Negotiation,” Proc. ACM Workshop Privacy in the Electronic Soc., ACM
Press, 2002, pp. 41–51.
6. E. Bertino, E. Ferrari, and A.C. Squicciarini, “Trust-c: A Peer-to-Peer Frame-
work for Trust Establishment,” IEEE Trans. Knowledge and Data Eng., vol.
16, no. 7, 2004, pp. 827– 842.

Table 1. Automated trust negotiation (ATN) vs. identity management (IdM) systems.
CRITERIA ATN SYSTEMS IDM SYSTEMS

Environment Open Closed

Credential management
Attributes used
Attribute encoding
Architecture
Policies
Policy language
Trust model
Unique identification
Credential discovery
User centric
Certified attributes or credentials
X.509 certificates, XML certificates
Peer-to-peer
Privacy policies, access-control policies
XML-based trust-negotiation language (X-TNL),
register transfer, Protune, and so on
Pairwise trust (some brokered trust)
Optional
Credential chain management protocols
Polycentric
Certified and uncertified attributes
Username, Security Assertion Markup Language (SAML)
assertions, X.509 certificates, Kerberos tickets
Client-server
Privacy policies, authorization policies
Extensible Access Control Markup Language (XACML)
Pairwise trust, brokered trust, community trust
Single sign-on required
Discovery service protocols

tion. Although recent work has looked at storing user save user profiles for future use in the federation accord-
credentials with SPs using anonymous credentials, most ing to the user’s privacy preferences.
ATN systems assume that users directly manage their ATNs typically negotiate certified attributes or cred-
own credentials. In IdM systems, on the other hand, SPs entials. IdM systems mainly use uncertified attributes, al-

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 57

 Identity Management
though they can also support certified attributes. IdM sys-
tems usually rely on Security Assertion Markup Language
(SAML) assertions for encoding attributes, whereas in
ATN systems, attributes are encoded in credentials, which
are the digital equivalent of physical certificates, repre-
sented according to the X.509 certificate format.
Architecture
An ATN system is typically used in peer-to-peer (P2P)
systems, so clients and servers have the same basic archi-
tecture. Any entity serving as provider in a trust negotia-
tion can act as a client in a different negotiation. In IdM
frameworks, IdPs, SPs, and clients all have different archi-
tectural components depending on that entity’s function-
ality. The P2P nature of ATN systems simplifies the
integration of an ATN’s architectural components with
the existing IdM systems.
Policies
Both IdM and ATN systems aim to satisfy user privacy
preferences for their personal data and to ensure that ac-
cess-control policies are stated and enforced. So, both
offer privacy and access-control policies. However, in
ATN systems, access-control policies play a key role in
the trust-negotiation processes, whereas they’re only a
marginal aspect in IdM systems. As such, ATN policies
can be more complex and provide alternative ways of sat-
isfying the requirements for access to a given resource or
expressing different usage conditions. This ensures
soundness for any transaction, meaning that if user prefer-
ences and the SP’s requirements are compatible, the trans-
action will certainly succeed. Soundness isn’t guaranteed
in current IdM systems because they lack formal negoti-
ation procedures and a corresponding expressive policy
language. However, IdM systems provide mechanisms
for policy exchange that additional negotiation modules
could use to provide ATN functions.
User identity
Both ATN and IdM systems require users to be identi-
fied. Such a requirement is particularly relevant in IdM
systems, which aim to uniquely identify users within fed-
erations. Users in an IdM mostly need an SSO to interact
with any SP in the federation and to ensure that their at-
tributes are linked to them. By contrast, identity is usually
a secondary aspect in ATN systems because authentica-
tion is based mainly on user properties rather than on the
sole identity. However, real case scenarios show that au-
thentication is often a first-class requirement in specific
negotiations. Further, IdM systems rely on SSO to iden-
tify users, so there’s no need to certify user identities in
other ways. ATN systems obtain identities using creden-
tial combinations, although they might use SSO in spe-
cific contexts. In ATN systems, there’s no need to link
multiple negotiations to the same identity because identi-
58 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
fication is (if required) executed on the fly, while the ne-
gotiation process is taking place.
Trust model
A typical IdM system has three types of trust models:4
• a pairwise model for two entities that have direct busi-
ness agreements with each other;
• a brokered trust model for two entities that don’t have a
direct agreement with each other, but have agreements
with one or more intermediaries so as to enable con-
struction of a business trust path between the two enti-
ties; and
• a community trust model for several entities that have
common business agreements within the community
or federation.
Although all three trust models can use ATN systems,
the brokered trust model integrated with ATN provides a
unique feature to existing IdM systems.
Other similarities
Both ATN and IdM also require credential discovery, al-
though they use different methods. Using a discovery ser-
vice, IdMs collaborate to make assertions about a user
from a local IdP to a remote IdP. Similarly, ATN systems
use credential discovery to retrieve remote credentials not
available at the negotiating parties.
Another related aspect is delegation. Although dele-
gation isn’t a main issue in trust negotiations, both IdM
and ATN systems achieve delegation through ad hoc
protocols and credentials enabling entities to negotiate on
behalf of third parties. In IdM systems, we can use the
brokered trust model to delegate the responsibility for at-
tribute assertion to another IdP that the user trusts more.
Integrating IdM
and trust negotiations
FAMTN combines the advantages of the IdM and ATN
approaches, providing a truly distributed approach to
managing user identities and attributes with negotiation
capabilities.
A FAMTN federation essentially involves two types
of entities: FAMTN service providers (FSP) and users. In
the FAMTN framework, we don’t distinguish between
SPs and IdPs: each SP in the federation can act as an IdP.
SPs exchange information through ATN, according to
an on-demand dynamic protocol. FSPs support identity
and attribute provisioning, as we detail later.
Our approach supports negotiations between an FSP
and the user, and between two FSPs in the same federa-
tion. The protocol for negotiations between FSPs and
users depends on the interacting user’s type. The distinc-
tion is based on the user’s membership in the federation.
A user who’s affiliated with an organization within the
 Identity Management

federation is a member user of the federation. The federa-

SP2 Attributes SP1 User
tion is more likely to have information about a member a, required by a, Request service from SP1 Tickets
user even if the member hasn’t accessed any of its services. c the service b {}

external user
This also depends on the member organization’s policy, policy Request user attr (a, b)
which defines which of its affiliated user attributes are

New
Give attr (a, b)
federated. An SSO user identification identifies the Provide service
member in the federation. and give ticket T1 {T1}
On the contrary, external users must provide all re- Request service from SP2
quired attributes at their first negotiation. The first nego-
Given T1 request
tiation between an external user and an FSP includes for user attr (a)
identity provisioning, because the provider issues a tem-

external user
porary user ID to be used within the federation. The use Give attr (a)

Repeat
of time-limited SSO ID for nonmembers ensures iden- Request for user attr (c)
tity linkability. (We can reasonably assume that the feder-
Give attr (c) {T1,
ation policy defines the time interval.) Of course, users T2}
might have multiple identities but choose to adopt one Provide service
for requesting access to service. We don’t elaborate on this and give ticket T2

issue because it goes beyond our article’s scope. By inter-

acting further with the federation, the amount of infor-
mation about users that is disclosed to the federation
increases. This information can be linked to the user
(who becomes a repeated external user) and thus reused in
the subsequent negotiations. As a result, the system exe-
cutes more efficient negotiations with fewer attributes re-
quired from the user.
Figure 1 shows an example. User U requests service
from service provider SP1, which requires user attributes
(a, b) to satisfy its service policy. U provides (a, b) and gets
the service. Suppose that U, at the end of this successful
negotiation, opts for sharing attribute (a) within the feder-
ation, and suppose that U then requires a service from an-
other provider SP2 in the same federation. Suppose that
the attribute requirements there are (a, c). In this case,
however, U only has to provide the attribute c to receive
the service.
At the end of a successful negotiation, users receive
one of two types of ticket:
• a trust ticket provides information about the previous
services and FSPs the user has accessed; and
• a session ticket provides recent history information to
help speed up negotiations, as we detail later.
The second type of negotiation occurs between two
FSPs. This negotiation type is useful when a user success-
fully negotiates a service from one FSP and automatically
becomes eligible to receive service from another FSP. As
such, when the user asks for a service, the FSP providing
it can directly negotiate user-related attributes with the
FSP holding such attributes from previous negotiations.
Also, negotiations among FSPs might be required for ver-
ifying external user identities. Because we don’t rely on a
single IdP, an IdP might not be aware of the last registered
users. When the FSP receives a request from a locally un-
known user ID, it can directly interact with the SP that is-
Negotiation between user and service provider
Negotiation between two service providers
Figure 1. External user negotiating with two service providers (SPs)
of a federation. A user who has already provided attributes to any SP
in the federation might not need to provide them again when
another SP in the federation requires them.
sued the claimed user ID to double check its validity (for
simplicity, we assume the user ID contains FSP informa-
tion to easily identify the issuer).
Architecture of
service providers in FAMTN
A FAMTN framework consists of an FSP containing the
necessary components required to execute two func-
tions: trust negotiation among users and FSPs and feder-
ation of user attributes.
Figure 2 shows the FSP architecture. An FSP’s com-
ponents derive from FAMTN’s two underlying frame-
works: ATN and federated IdM. Each FSP can perform
the functionality of an IdP and an SP.
The FSP’s main components are:
• the Web services component, which enables secure com-
munication within the federation and with the users; and
• the user negotiation component, which contains the mod-
ules executing the negotiation, depending on whether
the user is a member or nonmember (this component is
directly related to the trust ticket management layer).
Other parts of the FSP include the trust ticket manage-
ment layer which manages the trust tickets and the session
tickets required for the negotiation. The policy management

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 59

 Identity Management

5. SP1 negotiates with the IdP, which finally sends a

User
HTTP SOAP
User negotiation component
Trust ticket management layer
Other service providers
SAML assertion stating whether Joe satisfies SP1’s age
Web criteria. So, Joe doesn’t have to reveal the actual cre-
services dential to SP1, ensuring that the credential is stored
component
only with a trusted party.
6. Joe also registers his address with SP1 for delivery but
imposes as a condition that his address should be re-

Policy Credential
management Policy leased only to a member of the federation and only
management
HTTP SOAP

enforcement
system
when the address is required for a purchased product
Policy base
delivery and the member is certified by the Better
Attribute negotiation system
Business Bureau (BBB).
Tree manager Storage subsystem 7. Joe subsequently accesses SP2 to order a pizza. Be-
Sequence
cause of SSO he gets seamless access.
prediction User 8. SP2 asks Joe for his address. Joe tells SP2 to get his pro-
module profile file from other sites in the federation. (In this case, it’s
actually an agent operating at the client on behalf of
Joe that suggests request redirections. We use Joe to
Compliance checker simplify the example’s presentation.) Using the dis-
covery service, SP2 contacts SP1, who negotiates
with SP2 to verify that the conditions for Joe’s at-
Figure 2. The federated attribute management and trust negotiation tribute release are met. If the negotiation succeeds,
(FAMTN) service provider architecture. SP2 receives the required information and can make
the appropriate delivery.

and enforcement components store the authentication and
access-control policies in the policy base and enforce them,
respectively. The credential management system manages and
validates certificates and user tickets by verifying the FSPs’
signatures. It’s also responsible for revocation when re-
quired. The attribute negotiation system consists of the main
components required for negotiation:
• the tree manager, which stores the negotiation’s state;
• the storage subsystem containing the sequence prediction
module, which caches and manages previously used
trust sequences and user profile information; and
• the compliance checker, which tests policy satisfaction and
determines request replies during a negotiation.
An example use case
Figure 3 shows an example scenario of the Liberty Web
services framework (WSF)5 with additional FSP compo-
nents. (See the “Initiatives and systems” sidebar for more
on Liberty Alliance, which provides open standards for
SSO with decentralized authentication.) In this scenario,
the following steps take place:
1. A user, say Joe, accesses SP1 using SSO.
2. Using redirection and IdM system protocols, an IdP
transmits a SAML assertion authenticating Joe to SP1.
3. SP1 requires a certificate from Joe to verify his address
for delivery and that he is older than 21.
4. Joe doesn’t trust SP1 so won’t reveal his certified cre-
dential to it. He therefore negotiates with the IdP and
reveals his credential to it instead.
This example demonstrates how we can implement
additional privacy and flexible policies with ATN. Also,
not all FSP components are required in a typical IdM
system. FSP can leverage modules belonging to the Lib-
erty Alliance Framework or other IdM systems, such as
the discovery service (DS) and personal profile (PP) policy
and credential management systems. The ATN-specific
parts (the solid color components) in Figure 3 are the
subset of FSP components used for ATN in the Liberty
WSF framework.
Negotiations in
a FAMTN federation
Session tickets and trust tickets are the main building
blocks in our trust negotiation protocols. Both ticket
types are temporal with a fixed lifetime. We assume
loosely synchronized clocks in the federation. We use the
SSO ID as the user ID in the tickets.
A session ticket ensures that if the negotiation ends
successfully and the same user requests the same FSP for
the same service in a subsequent session, the system can
grant the service immediately without having to unnec-
essarily repeat the trust-establishment process. A session
ticket therefore contains the fields SignedFSP <␶(sreq), u, T,
R>, where ␶(sreq) denotes the service requested, u is the
user ID, and T is the ticket timestamp. Here, R denotes
the negotiation’s result and can be a simple statement or a
structured object. The use of structured objects is partic-
ularly interesting for tracing intermediate results of nego-
tiations of aggregated services.
The FSP signs a session ticket and gives a receipt of the

60 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007


trust establishment. Because session tickets are encrypted
with the FSPs private key, they are tamperproof and veri-
fiable. The time-out mechanism depends on the type of
user attributes required for the service, and the service’s
security level.
The trust ticket determines the list of services external
users have accessed. Assuming that all the FSPs are mem-
bers of the same federation, any member provider can
verify another member provider’s signature. Such a ticket
has the following form:
SignedSP
last
{ }
list τ ( s ) , FSP ,T u,T − I .
Every 3-tuple in the list contains the service type, the
corresponding FSP, and the timeout. The variable u cor-
responds to the temporary user identification, and T – I
is the ID’s expiration date. The ticket is signed by the last
FSP with which the user had a successful transaction. At
the end of a successful transaction, the FSP takes the cur-
rent user trust ticket, removes all timed-out entries, ap-
pends its information, signs it, and sends it to the user.
Implementing trust tickets
through cookies
Many IdM systems use cookies to make user information
available to servers. State information is stored at the
client, which sends the cookie to the server the next time
the user accesses that server. Like session and trust tickets,
cookies can be valid only for the session during which
they were issued or can persist beyond the session’s end. A
persistent cookie is typically written to a file on the
browser’s hard drive if its lifetime hasn’t elapsed when the
browser is shut down and therefore can be used for a
longer period of time. In a truly distributed federation
that has more than one IdP, an FSP needs a mechanism to
determine which IdP has the user information. In Lib-
erty, this problem is known as the introduction problem.
Currently, Liberty Alliance protocols rely on cookies for
redirecting IdPs.
Cookies offer several advantages. Implementing them
is efficient because you don’t need new software to use
them, and you can use them independently of any au-
thentication mechanism. They also provide dynamic
state information, which is helpful for preventing several
security threats. One such threat is an impersonation attack,
which arises when a user has successfully logged onto one
FSP, but the other FSPs in the federation don’t re-authen-
ticate the user. Thus if the authentication is no longer
valid, because of attacks or other failure, the FSP has no
straightforward way to detect it. Cookies help the FSP
check whether the authentication ticket is associated
with the user identity as well as whether the IdP session is
valid for that user. Alternatives to using cookies for the in-
troduction problem are based on interactions with the
user either actively or on the use of statically hand-config-
Identity Management
IDP: Identity provider
IDP DS DS: Discovery service
modules modules SP: Service provider
PP: ID-SIS personal profile
WSC: Web service consumer
WSP: Web service provider
IDP/DS
ATN modules
SP WSC SP WSP
modules modules modules modules
PP client PP client
modules modules
SP1 SP/WSC SP2 SP/WSP
Figure 3. Liberty Web services framework and federated service
provider with three Web sites and system modules. The arrows
indicate the possible communication of the various module sets.
ured lists of possible user IdPs. Such approaches inhibit
the seamless SSO process and are less efficient.
Cookies, however, have some security problems:6
• They’re usually in clear text. Headers are generally un-
protected, and even encrypted cookies are vulnerable
to replay attacks.
• Because cookies are stored on local machines, anyone
using the machine can easily read them.
• You need to control where cookies are sent, because
you wouldn’t want to send the user cookie to an un-
trusted service provider. For example, several current
spyware applications exploit user cookies, so we need
to better control cookies’ destinations.
Consequently, cookies shouldn’t store personal iden-
tifiers or sensitive information. In real applications, how-
ever, a cookie typically stores the SSO user ID or other
tracking record, which might leak information about the
user. Better storage and usage protocols and mechanisms
can address most of these security vulnerabilities. We pro-
pose implementing trust tickets in IdM systems using
cookies to exploit cookies’ advantages while preventing
the vulnerabilities we’ve just described. Indeed, the time-
outs and signed information given by the session and trust
tickets contain reliable and dynamic state information. To
further increase cookie security, federations should use
mechanisms enabling selective download of cookies.
Browsers typically give users limited choice about how to
handle cookies. Control is coarse-grained: the browser
will download no cookies or must accept all cookies. Let-
ting a user choose cookies from a Web site that uses a sin-
gle domain versus multiple domains can cause problems
in federations, which are typically multiple-domain envi-
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 61
 Identity Management

Require: userID, userAuthenticationInfo 24: send(SessionTicket)  userID

Ensure: IsRegistered(userID) 25: return OK
1: userRequest  getRequest(userID) 26: end if
2: if userRequest  ServicesFSP then 27: end if
3: return Abort-Negotiation 28: *Comment: For Non-Members*
4: end if 29: FSPlist  getTrustTicket(userID)
5: *Comment: For Members* 30: while FSPlist  EmptyList do
6: if isValidMember(userID) = true then 31: Mi = rmHeadOfList(FSPlist)
7: sessionTicket  getSessionTicket(userID) 32: remAttrList3  NEGOTIATEFSP (CurrFSP, Mi
8: if sessionTicket  NULL ^ 33: userID, userRequest)
sessionTicket.time < timeout then 34: if remAttrList3 = NULL then
9: return OK 35: send(TrustTicket)  userID
10: end if 36: return OK
11: MFSP = getMemberFSP(userID) 37: end if
12: remAttrList1  NEGOTIATEFSP (CurrFSP, MFSP 38: end while
13: userID, userRequest) 39: if remAttrList3  NULL then
14: if remAttrList1  NULL then 40: remAttrList4  NEGOTIATEUser(CurrFSP,
15: remAttrList2  NEGOTIATEUser(CurrFSP, 41: userID,CurrPolicyFSP)
16: userID,CurrPolicyFSP) 42: end if
17: else 43: if remAttrList4  NULL then
18: send(SessionTicket)  userID 44: return Abort-Negotiation
19: return OK 45: else
20: end if 46: send(TrustTicket)  userID
21: if remAttrList2  NULL then 47: return OK
22: return Abort-Negotiation 48: end if
23: else

Figure 4. Algorithm for negotiating trust in FAMTN.

ronments. Building server filters is currently complicated
and not feasible for average users. Like privacy prefer-
ences, a user should be able to set cookie preferences,
specifying more fine-grained conditions. For example,
• accept only signed cookies from a given federation FSP;
• accept cookies from BBB-certified members by nego-
tiating servers’ attributes;
• send cookies that don’t contain personally identifying
information; and
• send cookies to FSPs that aren’t in a conflict-of-interest
class for the FSP that set the cookie.
We need a policy language to express these prefer-
ences that can be integrated with cookies’ storage and
usage mechanisms.
Negotiation in identity federated systems
The trust-establishment negotiation process depends on
the type of user and the history of the user’s interactions
with the federation members. Algorithm 1 (Figure 4)
shows the complete negotiation process developed for
FAMTN. It includes all user cases, assuming one federa-
tion is in place. Multiple federations with nonempty in-
tersection are outside this article’s scope.
Four types of user cases give the basis of the design and
analysis of the user–FSP negotiation process. Intuitively, a
recent user should obtain service access faster than a new
user. The short-termed session tickets help achieve this.
Similarly, a repeat user, who has already received services
from different FSPs in the federation, should get service
access faster than a new external user. This is because the
new external user directly negotiates all the required at-
tributes with the FSP, whereas for a repeat user, the FSP
can retrieve some of the attributes from FSPs the user has
visited before. Information about the previously visited
FSPs is in the list of trust tickets, which are retrieved iter-
atively until user attribute requirements are satisfied. At
each iteration, the FSP requiring the user attributes to
satisfy its service disclosure policy negotiates with the FSP
indicated in the trust ticket. If the retrieved attributes
don’t suffice, the FSP negotiates directly with the user.
Finally, a member user, being internal to the federation
and thus more trusted, should have advantages in the ne-
gotiation process over a new external (nonmember) user.
Indeed, the FSP retrieves the member user attributes di-

62 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007

 Identity Management

Existing federations
F ederated identity can deliver several compelling benefits to organi-
zations. Federation makes it possible for local identities and their
associated data to stay in place, yet be linked together through higher-
level mechanisms. The following are examples of existing federations.
The SWITCHaai Federation (www.switch.ch/aai/documents.
html) is a group of organizations (universities, hospitals, and
libraries, for example) that have agreed to cooperate on inter-
organizational authentication and authorization. They operate a
Shibboleth-based authentication and authorization infrastructure
(see http://shibboleth.internet2.edu).
By using Shibboleth authentication and authorization technology,
InCommon (www.incommonfederation.org) facilitates sharing of
protected resources, enabling collaboration between InCommon par-
ticipants that protects privacy. Access decisions to protected resourc-
es are based on user attributes contributed by the user’s home
institution. InCommon became operational on 5 April 2005.
The HAKA Federation in Finland (www.csc.fi/suomi/funet/
middleware) entered its production phase in late 2004. The Fede-
ration, established in 2003 and based on Shibboleth, currently
includes two (of 20) universities and one (of 29) polytechnics as
identity providers, and four service providers, including the
National Library Portal (Nelli). In Finland, libraries in higher edu-
cation traditionally cooperate in licensing electronic journals.
The Liberty Alliance Identity Federation Framework (ID-FF)
allows single sign-on and account linking between partners with
established trust relationships. The Identity Web Services Frame-
work (ID-WSF) lets groups of trusted partners link to other groups
and gives users control over how their information is shared.
Finally, the Identity Services Interface Specifications (ID-SIS) will
build a set of interoperable services on top of the ID-WSF.

rectly from the organizations in the federation within
which users are affiliated. This provides an efficient
mechanism for retrieving users attributes because it
avoids iterated negotiations among all the FSPs a user has
interacted with. Here we assume that the affiliated orga-
nization stores and possibly certifies all of the member
users’ attributes. Member users can also use the session
tickets like the external users.
ACM Trans. Information Systems Security, vol. 7, no. 3,
2004, pp. 428–456.
4. Liberty Alliance Project, Liberty Trust Model Guidelines,
www.projectliberty.org/liberty/content/download/1232/
8000/file/liberty-trust-models-guidelines-v1.0.pdf.
5. Liberty Alliance Project, Liberty Alliance ID-WSF 2.0
Specifications, www.projectliberty.org/resource_center/
specifications/liberty_alliance_id_wsf_2_0_specifications.
6. V. Samar, “Single Sign-on Using Cookies for Web Appli-
cations,” Proc. 8th Workshop Enabling Technologies on Infra-

B efore we can fully integrate federated IdM systems and

trust-negotiation, several issues must be addressed, in-
cluding questions regarding policies—that is, policy com-
structure for Collaborative Enterprises (WETICE), IEEE CS
Press, 1999, pp. 158–163.

pliance and subsumption of policies. The language to
define the policies should use vocabulary well understood
not only by users and organizations, but by the whole set of
organizations. This might not be a realistic assumption, and
we need to look into alternatives. Policy languages sup-
porting the specification of credential sharing within a fed-
eration don’t exist and will be useful for better privacy
control in a federation. Another important problem is the
representation of attributes. This is essential for efficient
lookup if several users are using the system. The attribute’s
meaning and its underlying logic can also help users infer
implications between conditional attributes.
References
1. D.L. Baumer, J.B. Earp, and P.S. Evers, “Tit for Tat in
Cyberspace: Consumer and Website Responses to Anar-
chy in the Market for Personal Information,” North Carolina
J. Law and Technology, vol. 4, no. 2, 2003, pp. 217–274.
2. H. Skogsrud et al., “Trust-serv: A Lightweight Trust
Negotiation Service,” Proc. 30th Int’l Conf. Very Large Data
Bases, Morgan Kaufmann, 2004, pp. 1329–1332.
3. A. Hess et al., “Content-Triggered Trust Negotiation,”
Elisa Bertino is a professor of computer science and electrical
and computer engineering and research director at the Center
for Education and Research in Information Assurance and Secu-
rity (CERIAS) at Purdue University. Her main research interests
include security, database systems, object technology, multi-
media systems, and Web-based information systems. Bertino
has a PhD in computer science from the University of Pisa. She
is a coeditor in chief of the VLDB Journal and member of the edi-
torial boards of several publications, including IEEE Internet
Computing, IEEE Security & Privacy, and ACM Transactions
on Information and Systems Security. She is a Fellow of the
IEEE and the ACM. Contact her at bertino@cs.purdue.edu.
Anna Cinzia Squicciarini is a postdoctoral research associate at
Purdue University. Her main research interests range from trust
negotiations, privacy models, and mechanisms for privilege and
contract management in virtual organizations to grid systems
and federated identity management. Squicciarini has a PhD in
computer science from the University of Milan. Contact her at
squiccia@cs.purdue.edu.
Abhilasha Bhargav-Spantzel is a computer science PhD candi-
date at CERIAS, Purdue University. Her main research interests
include identity management, identity theft protection, cryptog-
raphy, biometrics, and policy languages. Bhargav-Spantzel has
a bachelor’s degree in computer science and mathematics from
Purdue University. Contact her at bhargav@cs.purdue.edu.

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 63

 Education
Editors: Matt Bishop, bishop@cs.ucdavis.edu
Deborah A. Frincke, deborah.frincke@pnl.gov

Common Body of Knowledge

for Information Security

T
he need for skilled information security professionals Australia (19), Europe (53), and
South and North America (44). We
has led various academic, governmental, and indus- based our review of these programs
and courses on electronically avail-
trial organizations to work to develop a common able material on the universities’
Web sites, as well as on a study of
body of knowledge (CBK) for the security domain. their syllabi. We found that 15 un-
dergraduate and 45 postgraduate-
A CBK is a framework and collection of information that provides level programs offer degrees in some
aspect of information security. Most
MARIANTHI a basis for understanding terms and cure software engineering and pro- of the programs offering informa-
THEOHARIDOU concepts in a particular knowledge curement of secure software. tion security degrees are run under
AND DIMITRIS area. It defines the basic information Information security is a multi- the umbrella of computer science or
G RITZALIS that people who work in that area disciplinary endeavor.6,7 In prac- computer engineering departments.
Athens are expected to know.1 The Interna- tice, professionals need knowledge At the postgraduate level, a usual
University of tional Information Systems Security and experience from fields such as prerequisite is an undergraduate de-
Economics Certification Consortium ([ISC]2; management, business administra- gree in computer science, electrical
and Business www.isc2.org) defines a CBK as a tion, ethics, sociology, and political and computer engineering, or in-
taxonomy of topics relevant to pro- science. Yet, existing CBKs focus formation systems. Several under-
fessionals around the world. on specific information security graduate (and graduate) programs
Industry has initiated some exist- subdomains and thus offer limited offer information-security-related
ing CBK efforts, primarily for use in understanding and narrow percep- courses, without offering degrees in
certification programs such as the tions of the overall domain. Our the subject. Such courses are usually
Certified Information Systems Se- aim is to identify and define an few in number and are often op-
curity Professionals (CISSP) and InfoSec CBK to serve as a tool for tional. Table 1 describes the course
Certified Information Systems Au- developing an information security content, which we divided into
ditor (CISA). The (ISC)2 CBK is curriculum. seven categories.
used for CISSP certification, for ex- To identify the essential skill set
ample, and focuses on establishing a CBK development for information security profession-
common framework of information We began by identifying industry als, we also conducted a survey of in-
security terms and principles to help and academic views on the issue of dustry needs. To that end, we
information security professionals an InfoSec CBK. We first conducted consulted the online material pro-
discuss, debate, and resolve relevant a review of curricula and courses. vided by the Career Space Consor-
issues. Typical academic examples Various curricula deal with InfoSec tium (CSC; www.career-space.com),
include CBKs for information assur- topics, but we focused on university which includes 11 major informa-
ance,2 information security in net- programs related to the “informa- tion and communications technol-
work technologies,3 and information tion scene”—computer science, ogy (ICT) companies as members,
security professionals.4 Rather than business administration, informa- and the European ICT Industry As-
providing an information security tion systems management, sociol- sociation (www.eicta.org). CSC de-
CBK, these efforts focus on individ- ogy, and law programs that offer fines ICT professional areas and the
ual subdomains and serve as guides academic degrees in, or courses re- skills needed for each, but it doesn’t
to create courses and curricula.2,3 A lated to, InfoSec. In total, we studied define a “pure” InfoSec professional
recent US Department of Home- the programs and courses currently area. To select relevant ICT areas, we
land Security initiative created a offered at 135 academic institutions. studied the content of the security
CBK for secure software assur- The per-continent geographical dis- courses we identified previously.
ance,1,5 which provides a basis for se- tribution was: Africa (10), Asia (10), As defined by the CSC, the ICT

64 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY
 Education

Table 1. Information security course content.

CATEGORY COURSE TOPICS

Access control Identification, authentication and authentication systems, access control, authorization, anonymity, and privacy
and privacy
Risk and attacks Attacks, vulnerabilities, risks, intrusion detection, malicious software, tests and audits, safeguards, and intrusion handling
Cryptography Applied cryptography, digital signatures and certifications, key management, and public-key infrastructures
Networks Security theory, protocols and algorithms of networks, and firewalls
Security design Computer systems security design
Business Business continuity planning
Ethics and law Ethical and legal issues

Table 2. Technical and behavioral skills for information security professionals.

CATEGORY SKILLS

Information Networks, technology and computer engineering, systems design and architecture, programming, software
Communications development, mathematics, statistics, project management, business strategy and requirements analysis, testing, basic
Technology security skills, technical documentation, system management, quality assurance, and evaluation and configuration
methodologies.
Security Information security and human computer interaction, computer forensics, database security and data mining,
operation systems security, security architecture, malicious software, Internet and cybersecurity, incident handling,
hacking, cryptography, biometric techniques, smart cards, auditing, data and infrastructure protection, and risk
management.
Behavioral Leadership, ethics, analytical and conceptual thinking, perspicacity, creative thought, knowing one’s limits, professional
attitude, communication, technical orientation and interest, customer orientation, strategy and planning, writing and
presentation skills, efficiency and quality, and applying knowledge.

professional areas that refer to secu-
rity knowledge include:
• integration and test engineering,
• systems,
• data communications engineering,
• digital signal processing (DSP) ap-
plication design,
• technical support,
• communication network design,
• software and application develop-
ment,
• software architecture and design,
• research and technology develop-
ment,
• ICT management,
• IT business consultancy, and
• ICT project management.
We surveyed the skills needed for
each of these ICT categories, as de-
fined by the CSC. To filter and en-
rich the skill set, we used numerous
security job descriptions that we
identified from online job postings.
Table 2 shows the resulting skill set,
which we used as a baseline for de-
veloping our proposed CBK.
Structure and content
We developed a hierarchy of con-
cepts and elements from the univer-
sity curricula we examined and
checked it against the knowledge set
defined in the industry surveys. Fi-
nally, we combined these elements
and grouped them under common
“roots” (hash algorithms and ciphers
under the root cryptography, for ex-
ample) to create a classification
scheme with 10 basic domains:
• Security architectures and models
• Access control systems and
methodologies
• Cryptography
• Network and telecommunica-
tions security
• Operating system security
• Program and application security
• Database security
• Business and management of in-
formation systems security
• Physical security and critical infra-
structure protection
• Social, ethical, and legal consider-
ations
We then split the list into subdo-
mains, according to the elements that
form each domain; doing so lets us
focus in depth on each separately.
This CBK aims to reconcile industry
and academia needs and reflect infor-
mation security’s multidisciplinary
nature.7–9 It covers multiple dimen-
sions, including governance, ethics,
policies, certification, measurement
and metrics, and best practices.
Moreover, we identified the prereq-
uisite knowledge that professionals
should incorporate from several fun-

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 65

 Education

*Business
security aspect grouped in the
Incidence management “physical security and critical infra-
*Law
Use of response structure protection” domain. Note
Law
protection *Didactic that some elements are included in
mechanisms more than one domain. The aster-
Risk Security Security training and
management staff awareness of users isks in the figures illustrate which
disciplines (of the seven we identi-
Business and
Operations for system assurance Security in fied) each topic mainly derives from.
management of
information work duties
Access control systems security
Disaster
Processes and duties
in organization’s operation
Business
recovery plan
W e developed this broad CBK
primarily as a conceptual tool
for designing academic curricula
Data storage management continuity plan *Business management
*Computer engineering
*Computer science
and information security courses.
Practices and security models
It’s intentionally abstract and ge-
neric because it attempts to catego-
Figure 1. Business and management of information systems security domain. Among rize the required knowledge for the
the issues raised in the university curricula and professional duties we surveyed related information security area, rather
to organizational issues in information security were personnel security, including than specific topics of interest. Al-
training and awareness programs (derived from didactics science), and business though any CBK needs to be con-
continuity planning (derived from business management). Asterisks indicate the stantly refined to fit into the field’s
disciplines from which the domains derive. emerging context and content, we
believe the 10 domains we’ve iden-
tified could remain a steady refer-
*Psychology *Ethics
ence set for some time.
E-voting and Ethics and Given that this CBK has yet to
Analysis of human behavior *Didactic
e-government ethical see thorough use in developing an
in breach and attack issues Training programs
services awareness academic curriculum, evaluation re-
sults aren’t available. Our future goal
Social, ethical, and is to use it to develop an MSc pro-
Psychology legal considerations Criminology E-crime
of security in gram on information security and
Research and critical infrastructure protection.
Speech freedom and censorship information security
computer forensics
Toward that end, we first plan to
New technologies Forensics Digital restructure some existing courses
Privacy
and economic growth analysis evidence in existing information security
Social practices in of security *Law
identities encryption *Economy courses, based on this CBK—proba-
incidences *Criminology
*Computer science bly a general introductory course
*Sociology
(undergraduate at senior level) and a
technology-focused postgraduate
Figure 2. Social, ethical, and legal considerations domain. The study of sociology, course that covers material from one
criminology, and psychology can help security professionals in understanding the or more domains. Once we actually
motives and social factors that affect human behavior and lead to security violations. deliver these restructured courses,
Moreover, the study of ethics and legal issues are vital in protecting human rights, and we will perform a round of refine-
information security professionals should not only comprehend and know the relevant ments and possible improvements
legal issues but also be able to apply them with respect to computing. with the CBK. We’ll then continue
to evaluate it based either on the ex-
perience gained from restructuring
damental disciplines: computer sci- ical, and legal considerations of secu- the rest of the existing courses or on
ence and engineering, law, sociology rity” (Figure 2)—demonstrate how developing essential new ones.
and criminology, ethics and psychol- multidisciplinary elements can be
ogy, business and information sys- incorporated into the CBK. Figure References
tems management, and didactics. 3 illustrates the “cryptography” do- 1. M. Bishop and S. Engle, “The Soft-
Two domains—“business and main, a topic with mathematical ware Assurance CBK and Univer-
management of information systems background that’s included in most sity Curricula,” Proc. 10th Colloq.
security” (Figure 1) and “social, eth- syllabi. Figure 4 presents the physical Information Systems Security Education,

66 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007

 Education

Univ. of Maryland, 2006, pp. 14-21. *Computer science management

*Law Types of Cryptographic
2. E. Crowley, “Information System ciphers checksums
Security Curricula Development,” Law
Third trust parts (TTP)
Proc. 4th Conf. IT Curriculum, ACM
Press, 2003, pp. 249–255. Authentication/ Public-key infrastructure (PKI)
identification
3. K. Morneau, “Designing an Infor- Cryptographic key infrastructures
mation Security Program as a Core
Competency of Network Technol- Cryptanalysis Cryptology Key management
Public key, digital signatures
ogists,” Proc. 5th Conf. IT Education,
ACM Press, 2004, pp. 29–32.
Methods of Cryptosystems attacked and cryptanalytic attacks
4. E. Smith et al., “Information Secu-
encryption
rity Education: Bridging the Gap and decryption
between Academic Institutions and Hash algorithms
Cryptographic Cryptographic
Industry,” Proc. 4th IFIP World Conf. security protocols security models
Information Security Education,
Moscow Engineering Physics
*Prerequisites: Mathematics (probability theory, number theory)
Institute, 2005, pp. 45–55.
5. S. Redwine, ed., Secure Software
Assurance: A Guide to the CBK to Figure 3. Cryptography domain. This topic derives from computer science and
Produce, Acquire and Sustain Secure mathematics, but InfoSec professionals should also examine the legislative and law
Software, US Dept. of Homeland enforcement issues.
Security, 2006.
6. D. Gritzalis, M. Theoharidou, and
E. Kalimeri, “Towards an Interdis- *Computer science
ciplinary InfoSec Education *Computer engineering
*Mechanism engineering
Model,” Proc. 4th IFIP World Conf. *Cryptography
Information Security Education, Countermeasures,
Media storage requirements processes, and Applied
Moscow Engineering Physics safeguards cryptography
Institute, 2005, pp. 22–35.
7. C. Cresson-Wood, “Why Infor- Tracking technologies Law *Law
mation Security is Now Multi-
Physical security
Disciplinary, Multi-Departmental, and critical
Environment/infrastructure Ethics *Ethics
and Multi-Organizational in protection from fire
infrastructure
Nature,” Computer Fraud & Security, protection
Elsevier, 2004, pp. 16–17. Perimetric security
Vulnerabilities
8. C. Irvine, S.-K. Chin, and D. and threats
Protection and monitoring mechanisms
Frincke, “Integrating Security into Security controls *Physics
the Curriculum,” Computer, vol. Person/personnel access control *Didactic
31, no. 12, 1998, pp. 25–30.
Administrative Technical/ Physical
9. K. Petrova et al, “Embedding Infor- Infrastructure access control controls logical controls controls
mation Security Curricula in Exist-
ing Programmes,” Proc. 1st Ann.
Conf. InfoSec Curriculum Develop-
ment, ACM Press, 2004, pp. 20–29. Figure 4. Physical security and critical infrastructure protection domain. Interesting
aspects of this domain are the physical threat and vulnerabilities, as well as ethical and
Marianthi Theoharidou is a PhD candi-
legal constraints when applying access control or surveillance in physical sites.
date in the department of informatics at
Athens University of Economics and
Business. Her research interests include Dimitris Gritzalis is an associate pro- management, information security edu-
information security management, infor- fessor of information and communica- cation, security and privacy in ubi-
mation security education, risk analysis tions technology security and the quitous computing, and spam over
and management, and spam over Inter- director of the Information Security and Internet telephony. Gritzalis has a PhD
net telephony. Theoharidou has an MSc Critical Infrastructure Protection re- in security critical information systems
in information systems from the Athens search group with the department of from the University of the Aegean,
University of Economics and Business. She informatics at Athens University of Eco- Greece. He is the editor of Secure Elec-
is a student member of the ACM and the nomics and Business. His research in- tronic Voting (Kluwer, 2003). Contact
IEEE. Contact her at mtheohar@aueb.gr. terests include information security him at dgrit@aueb.gr.

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 67

 On the Horizon
Editor: O. Sami Saydjari, ssaydjari@cyberdefenseagency.com

Secure Communication
without Encryption?

T
he potential computational speedup that quantum have a qubit in our possession, and
we know the basis in which it was
algorithms offer in certain problems threatens the prepared, then we can interact with
the system by performing a mea-
security of current cryptographic techniques that surement on it, the result of which
will be the classical bit’s value. This is
rely on the infeasibility of factoring large numbers. why we must know the basis: it tells
us the type of experiment we need
But the same technology that currently threatens public-key to perform in a laboratory. Remem-
ber, our bits may be represented by
KEYE MARTIN infrastructure also provides a seem- a way to communicate when they photons!
US Naval ing alternative: a protocol for quan- don’t want anyone else to know Now think of Eve, an eavesdrop-
Research tum key distribution (QKD), which they’re communicating. What we per trying to listen in on Alice and
Laboratory provides a secure method for estab- consider shortly is a hidden channel Bob. Alice sends many qubits |* to
lishing a secret key between two par- within QKD. Two people, Alice Bob, each one prepared in a different
ticipants. These two people can then and Bob, will engage in a typical in- basis. Eve has no idea what basis Alice
use this key to encrypt information, stance of QKD that, to an outside used, so all she can do is guess and
providing them with the ability to observer, looks like any other. But then perform a measurement (qubits
communicate securely. QKD has when the session is over, they will can’t be copied); Bob has to do the
been implemented numerous times, have secretly communicated. Put same thing. But Alice knows the
and it’s commercially available. succinctly, Alice and Bob say one basis used and can tell Bob after the
Recent investigations1 reveal that thing but mean another. fact without disclosing the identity of
fundamental quantum components Like all systems, a quantum system any of the bits. Because Bob will
such as QKD can be manipulated in has state. A quantum system’s state is guess the correct basis half the time,
ways not anticipated until recently. represented mathematically by vec- he should possess half the classical bits
Using any of several techniques rang- tors such as |0 and |1 or |– and sent by Alice. However, if Eve
ing from simple covert tricks to more |+ We think of the first two states as guesses a basis and then measures
intricate aspects of quantum infor- quantum realizations of the classical each qubit as it travels from Alice to
mation, someone can use a quantum bits 0 and 1, but we also think the Bob, she will introduce errors into
protocol to obtain a new protocol same about the second pair of states. the bits that Alice and Bob share. By
that’s physically indistinguishable These states are examples of what are comparing their respective values for
from the original, but that also con- often called qubits. Suppose that just some of the shared bits, Alice and
tains an information channel whose someone sends us a qubit |* that Bob can detect Eve’s presence.
existence is undetectable by any cur- represents either a 0 or a 1. How can Now let’s recall one of the stan-
rently known technology. Such “hid- we figure out which bit it represents? dard schemes for QKD, the BB84
den channels” could potentially The short answer is that we can’t! For protocol:2
provide secure communication with- us, as people who would like to com-
out encryption: the protection that municate, this is annoying, but it’s 1. Alice chooses a random string k
quantum mechanics offers to keys equally annoying to an eavesdropper, of roughly 4n bits containing the
could extend to the information and this is a good thing. eventual key.
transmitted during communication To determine the value of a bit 2. Alice randomly codes each bit of
itself, making key-based encryption that someone sends us, we also need k in either the X = {|+, |–} or
unnecessary. to know in which basis it was pre- Z = {|0, |1} bases.
pared. One example of a basis is the 3. Alice sends each resulting qubit
A hidden channel X basis, X = {|+, |–}, and another to Bob.
A hidden channel offers two people is the Z basis, Z = {|0, |1}. If we 4. Bob receives the 4n qubits, ran-

68 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY

domly measuring each in either
the X or Z basis.
5. Alice announces in which basis
she originally coded each bit of k.
6. Bob tells Alice which qubits he
measured in the correct basis (but
not the bit values he obtained);
they now share roughly 2n bits.
7. Alice selects a subset of n bits
from the group she formed in
step 6 that they will use to check
on interference by an eavesdrop-
per (Eve), and tells Bob which
bits she selected.
8. Alice and Bob compare their
values of the n check bits; if
more than an acceptable num-
ber disagree, they abort the pro-
tocol (eavesdropping).
9. Alice and Bob perform infor-
mation reconciliation and pri-
vacy amplification to select a
smaller m-bit key from the re-
maining n bits.
Throughout the literature, QKD
is loosely considered to be “commu-
nication,” but strictly speaking, it re-
ally isn’t. Communication is the
transfer of information from a sender
to a receiver, with the implicit under-
standing that the information re-
ceived is independent of any action
on the receiver’s part. This indepen-
dence is what makes communication
a worthwhile endeavor: it grants the
sender the freedom to say whatever
he or she wants. If, for example, you
talked to a friend on a noiseless tele-
phone and he received a subset of
roughly half the words you spoke,
and if this subset were randomly de-
termined by the number of times a
hummingbird in the room flapped its
wings between words, you wouldn’t
feel as though communication were
taking place. And that’s exactly what
goes on with QKD.
Ideally, Alice hopes Bob will re-
ceive the entire bit string k correctly,
but even in the absence of both envi-
ronmental noise and eavesdropping,
Bob still receives only half the bits in
k, and this half is randomly deter-
mined by his ability to guess the basis
in which Alice prepared the qubit.
The key that Alice and Bob eventu-
ally share is thus determined by an in-
teraction between the two parties. So
Alice isn’t really sending Bob infor-
mation, she’s sending him data—to
send him information would imply
that she decides up front on a mes-
sage and that he receives it with high
probability, independent of his own
actions. In other words, communi-
cation occurs when Alice has some
measure of control over the data Bob
receives. To quote from a standard
reference on quantum information,1
“Quantum cryptography is
sometimes thought of not as
secret key exchange or trans-
fer, but rather as secret key gen-
eration, since fundamentally
neither Alice nor Bob can pre-
determine the key they will ul-
timately end up with upon
completion of the protocol.”
However, we can easily modify the
QKD protocol so that Alice and
Bob are able to communicate. As-
sume Alice wants to send Bob a sin-
gle bit of information. All we have to
do is make a simple change to step 7
from earlier: Alice randomly selects a
bit from the group of 2n whose
value is the information she wants to
transmit. Then she randomly selects
n – 1 check bits from the remaining
2n – 1. The nth check bit is chosen
from the remaining n + 1 as being
the bit to the immediate left of the
information. (The case when the 2n
Communication is the transfer of information
from a sender to a receiver, with the implicit
understanding that the information received is
independent of any action on the receiver’s part.
bits are all 0 or all 1 is handled with a
simple convention—for example,
we could choose the nth check bit as
the first of the remaining bits to
www.computer.org/security/
On the Horizon
mean 0, whereas choosing it as the
last of the remaining bits would sig-
nify 1.)
Bob now has the information
Alice sent; he knows its relation to the
last check bit because the two parties
have agreed on this scheme in ad-
vance: they have agreed that Alice
will covertly send Bob a pointer to
the information. To illustrate how the
hidden channel operates, suppose
that Alice and Bob share the 2n bits
001010111001010111
0101101100
Alice first selects the information bit
(the one with a bar over it)
00101011100101011 1
0101101100
and then selects n – 1 check bits at
random (shown in bold):
00101011100101011
1 0101101100
One by one, these check bits are
publicly announced and their values
are compared. Alice and Bob now
share n+1 bits. She now selects the
last check bit as the pointer to the in-
formation (in bold):
0*10*01*1*0*0*0**
1 *10*1*11**
Is Bob guaranteed to receive the
information Alice sent? No, but he
isn’t guaranteed to receive all the bits
perfectly in the QKD case either.
Suppose an eavesdropper measures
only the qubit that holds the infor-
mation in the wrong basis—if so,
■ IEEE SECURITY & PRIVACY 69
 On the Horizon
Bob has a 50 percent chance of hold-
ing the wrong bit, even though he
believes he has the right bit—or sup-
pose background radiation acts as
Communication without encryption certainly
seems possible: the natural encryption that
quantum mechanics offers replaces
mathematical encryption.
noise and causes the information bit
to flip. In either case, Bob would
have no idea and neither would
Alice, but chances are good that such
errors would manifest themselves in
the check bits as well, which would
then help Bob and Alice determine
in advance the likelihood of success-
ful communication. There are,
however, major differences between
these two formulations of QKD:
• In QKD, Alice sends Bob data. In
the modified version, she sends a
bit of information—that is, data
she has control over. They’re
communicating.
• The information they exchange is
secure, so in principle, keys aren’t
necessary. They’re communicat-
ing securely without encryption.
• Communication between them is
hidden; to an outside observer, the
protocol looks like any other
instance of QKD. No observable
differences can tip off an eaves-
dropper that covert commu-
nication is taking place. The
communication is steganographic.
It’s worth going into more detail
on why this form of steganographic
communication is secure. Suppose
an eavesdropper, perhaps after read-
ing this article, assumes Alice and
Bob are using the channel described
earlier to secretly communicate.
Alice and Bob don’t have to use the
leftmost bit as a pointer—in general,
they can use a bit that is displaced any
number of positions from the infor-
70 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
mation bit. Knowing this, an eaves-
dropper would have to determine
which displacement they were using,
by observing several trial runs of
QKD. But if Alice sends bits across
the hidden channel with equal fre-
quency (something guaranteed to
achieve at least 94 percent of the hid-
den channel’s capacity), all displace-
ments appear equally likely to an
outside observer: the values in all
other locations are also equally dis-
tributed, due to the fact that k is ran-
domly generated. Eve might then
decide to simply try and match the
bits in a fixed location to a coding of,
say, the English alphabet. The prob-
lem for her then is that she won’t
know the value of the bit in a fixed
location every time QKD is run, but
at best, every other time: at least half
the bits in the code words she ob-
serves will be bits that Eve herself has
guessed. The reason why is that
quantum mechanics forces Eve to
guess a basis before measuring a
qubit. In fact, if Alice and Bob wish,
they can use a random value of dis-
placement each time a bit is commu-
nicated over the hidden channel by
using the key generated in the previ-
ous QKD session.
A critique
Communication without encryp-
tion certainly seems possible: the
natural encryption that quantum me-
chanics offers replaces mathematical
encryption. But could a scheme like
this ever provide a practical alterna-
tive to current forms of secure com-
munication? We must resolve some
unanswered questions:
• Can a hidden channel in a quan-
tum protocol achieve high enough
bandwidth to be a feasible alterna-
tive to present schemes? What is its
capacity per unit time?
• How will two people communi-
cate in this manner if they’re sepa-
rated by a large distance, such as an
ocean?
Transmitting qubits over large
distances would require the use of
satellites. If these satellites were
placed into geostationary orbit, we
might need huge light-gathering
mirrors to prevent photon loss,
which seems impractical at high
orbit. Fortunately, research at Los
Alamos National Laboratory has es-
tablished the feasibility of free-space
QKD between a ground station and
a low-Earth-orbit satellite.3
To gauge what a hidden channel
could offer, we must be able to mea-
sure the amount of information we
can send through one, but in a way
that takes into account the physical
effort required to transmit this infor-
mation. Of particular interest to us is
the capacity per unit time—the
amount of information the channel
can transmit per second.
In information theory,4 capacity
is usually calculated in units of ca-
pacity per unit symbol—that is, the
amount of information transmitted
per use of the channel, which im-
plicitly assumes that the cost of send-
ing one symbol is the same as the
cost of sending any other symbol.
But would you really want someone
to tell you that “on average, one bit is
transmitted per use of the channel”?
One channel could take two days to
transmit a bit, another could take less
than a fraction of a second—which
channel are they describing? Clearly,
we’re interested in determining ca-
pacity per unit time, which will re-
quire us to model the effect of
environmental noise on qubits in
transit.
It might also require us to under-
stand more subtle aspects. The re-
ceiver in this channel is a satellite in
low-Earth orbit, and information

theory wasn’t developed on the as-
sumption that the receiver might be
moving. Because our satellite is in
low orbit, a clock running on it
moves slower than one on the
ground due to time dilation, which
occurs not only because it’s moving
relative to Earth, but also because it’s
close to Earth (and feels gravitational
effects). Thus, capacity per unit time
depends on frame of reference. So
how do we determine the capacity
of a relativistic timing channel?
Which clock are we supposed to
use? Barring a cascade of such chan-
nels, each passing messages from one
to the other, we would guess that the
relativistic correction to capacity
wouldn’t affect our calculations
much. However, the relativistic cor-
rection to time itself seems especially
relevant if the sender wants to time
stamp messages before transmitting
them to the satellite—the receiver
needs to know how the time on his
or her clock relates to that on the
sender’s, or else time stamping might
impart incomplete information. (It’s
intriguing to wonder if relativistic
effects might also come into play in
QKD implementations based on
entangled pairs of qubits: photon
entanglement can also depend on
frame of reference.5)
Let’s now obtain a rough idea of
how the hidden channel might per-
form in a freespace QKD setup. We
will assume that each instance of
QKD always runs to completion and
takes roughly 1 second to do so, with
respect to the sender’s clock. Notice
that this means we ignore extreme
effects by an eavesdropper whose in-
terference causes us to abort the pro-
tocol and run it again, thereby at least
doubling the time it takes to send a
particular bit. It also means that we
assume the environment doesn’t
generate error rates that require us to
abort. Minimally, then, the percent-
age of errors p in the 2n bits shared by
Alice and Bob must be strictly less
than 0.25, which is the error rate due
solely to Eve when she measures all
qubits sent from Alice to Bob.
In several trial runs of freespace
QKD,6 error rates p in the 2n bits
shared by Alice and Bob ranged from
a high of p = 0.089 to a low of p =
0.006, with the great majority being
p = 0.04 or less. A lower bound on
the hidden channel’s capacity in this
experiment is obtained by calculat-
ing the capacity of a binary symmet-
ric channel whose probability of a bit
flip is p. Thus, the hidden channel’s
capacity ranges from a low of 0.566
bits/sec to a high of 0.947 bits/sec,
with an average of roughly 0.75
bits/sec, where the maximum possi-
ble capacity is 1 bit/sec. Although
space prohibits going into details
here, the information Eve can ac-
quire per second ranges from a high
of 0.00000043 bits/sec to a low of
0.0000000019 bits/sec. Notice that
these results highlight a fundamental
difference between classical and
quantum communication: as the
noise in the hidden channel de-
creases, an eavesdropper is able to
learn less and less. The explanation
for this is quantum mechanical in na-
ture: eavesdropping necessitates the
introduction of noise.
W e’ve purposely avoided one
question in this discussion: in
the hidden channel, we assumed
Alice and Bob had some way of au-
thenticating each other’s identity,
but can they do this in a uniquely
quantum mechanical manner? No-
tice that the QKD protocol doesn’t
provide a way for either of them to
know who they’re talking to. Bob
could be engaging in QKD with
anyone—he has no way of know-
ing—and what’s the point of secure
communication if you don’t know
who you’re talking to?
References
1. K. Martin, Steganographic Commu-
nication with Quantum Information,
tech. report, US Naval Research
Lab., to appear in 2007.
2. M. Nielsen and I. Chuang, Quan-
tum Computation and Quantum
www.computer.org/security/
On the Horizon
Information, Cambridge Univ.
Press, 2000.
3. R.J. Hughes et al., “Practical Free-
Space Quantum Cryptography,”
Proc. Quantum Computing and
Quantum Communications: First
NASA International Conference,
LNCS 1509, Springer-Verlag,
1999, pp. 200–213.
4. C.E. Shannon, “A Mathematical
Theory of Communication,” Bell
Systems Technical J., vol. 27, July–Oct.
1948, pp. 379–423 and 623–656.
5. A. Bergou, R. Gingrich, and C.
Adami, “Entangled Light in Mov-
ing Frames,” Physical Rev. A, vol.
68, no. 042102, 2003.
6. J.E. Nordholt and R.J. Hughes, “A
New Face for Cryptography,” Los
Alamos Science, no. 27, 2002, pp.
68–86.
Keye Martin is a researcher in the Center
for High Assurance Computer Systems at
the US Naval Research Laboratory. His
research interests include relativistic and
nonrelativistic quantum information,
domain theory, and information hiding.
He has a PhD in mathematics from
Tulane University. Contact him at
kmartin@itd.nrl.navy.mil.
IEEE
Computer save
Society
members
25%
on all
conferences
sponsored
by the
IEEE
Computer
Society
w w w. c o m p u t e r. o r g / j o i n
■ IEEE SECURITY & PRIVACY 71
 Privacy Interests
Editors: E. Michael Power, michael.power@gowlings.com
Roland L. Trope, roland.trope@verizon.net

Setting Boundaries at Borders

Reconciling Laptop Searches and Privacy

I
f you’ve traveled internationally on business, the odds are that this debate has already started
in the US and Canadian courts.
that you’ve taken your laptop with you. Like most busi-
Border searches
ness travelers, you need these ubiquitous devices to do One perspective (known in the US
as the border search doctrine) is that a
work, make presentations, and communicate with search is reasonable simply because it
occurs at the border.2,3 This rests on
coworkers, family, and friends via the Internet. In a previous the view that the government’s inter-
est “in preventing the entry of un-
E. M ICHAEL department, we explored the notion This last question is particularly vex- wanted persons and effects is at its
POWER AND that laptops deserve special considera- ing in light of the increasing probabil- zenith at the international border.”2
JONATHAN tion because of the increasingly ity that, in the absence of a The search of a traveler’s effects and
G ILHEN blurred line between home and of- well-founded, particularized suspi- containers such as luggage, pocket-
Gowling fice, the entrusting of intimate, pri- cion, most travelers’ laptops will carry books, and briefcases—which the
Lafleur vate information to storage on personal or commercially sensitive courts would elsewhere view as so
Henderson laptops, and the resulting need to re- information, and few will be used to invasive that it would require a war-
LLP think the rules surrounding reason- smuggle dangerous contraband. rant—are deemed so necessary and
able expectations of privacy.1 This As courts grapple with such routine at border checkpoints that
ROLAND L. time, we examine the nexus between questions, they will attempt to they may be conducted without a
TROPE laptops, a government’s search and compare the unfamiliar to some- warrant and without a well-founded,
Trope and seizure powers, and a traveler’s tran- thing more familiar, using analogies particularized suspicion (a probable
Schramm LLP sit through an international border or metaphors to solve new prob- cause) to target one traveler instead
checkpoint where customs officials lems based on earlier solutions. The of another—they can simply target
have enhanced powers to search trav- analogies the courts choose will any traveler passing through the
elers and their belongings. strongly influence the judicial dis- checkpoint. However, some border
This collision of interests between course and potentially alter the de- searches (such as strip searches) are so
a person’s right to be secure from un- cisions rendered. Are laptops nonroutine, because they are highly
reasonable searches and seizures and a merely luggage packed with data intrusive of a person’s privacy and
government’s obligation to protect that can be easily rummaged in the dignity, that US courts require that
its borders from the smuggling of il- course of a government search? they be based on what various courts
licit materials and other informa- Should they instead be viewed as refer to as a heightened level of suspi-
tional contraband via laptops and personal libraries whose volumes cion, a particularized suspicion,4 or
other storage devices has recently be- include many unpublished, in- “real suspicion” supported by “ob-
come ripe for decision by courts that tensely private writings composed jective, articulable facts”5 in order to
must answer three questions: in the belief that, like personal let- be reasonable without a warrant.
ters, diaries, or attorneys’ trial- At issue is whether the border
• How should the law treat a laptop strategy notes, they would not be search doctrine should include an
when the government wants to made public, and therefore require exception based on the privacy and
search and seize its contents? protection against warrantless, un- confidentiality of information in-
• How should that treatment change reasonable searches and seizures as creasingly stored on laptops—a posi-
when a traveler brings the laptop part of the owner’s basic human tion advanced in the November
into a border checkpoint? rights? Although some might ques- 2006 case of United States v. Arnold.
• What deference, if any, should the tion how laptops could form the
courts give to privacy interests at battleground for such an important The Arnold case
border checkpoints? discussion, several cases indicate In July 2005, after a nearly 24-hour,

72 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY
 Privacy Interests

coach-class flight from the Philip- ment violated the US Constitution’s tors’ and corporate execu-
pines, Michael Arnold arrived at Los Fourth Amendment (which pro- tives’ computers may contain
Angeles International Airport. He tects the “right of the people to be trade secrets.”6
collected his luggage and stood in secure in their persons, houses, pa-
line to go through the customs pers, and effects, against unreason- The court concluded that the gov-
checkpoint. US Customs and Bor- able searches and seizures”). ernment’s search didn’t originate
der Patrol (CBP) Officer Peng asked The US District Court, Central with a well-founded, reasonable sus-
a few routine questions and in- District of California, granted Ar- picion, and therefore should have
spected Arnold’s luggage and carry- nold’s motion, reasoning that the na- complied with the Fourth Amend-
on bag, which contained what many ture of information entrusted to ment’s warrant requirements. The
travelers today have in carry-on laptops and other electronic storage court’s determination of a lack of
bags: a laptop computer, a separate devices “renders a search of their reasonable suspicion rested on the
hard drive, a memory stick, and sev- contents substantially more intrusive fact that Officer Peng:
eral CDs. Officer Peng made the than a search of the contents of a
customary request that Arnold turn lunchbox or other tangible object.”6 • had only a vague and inconsistent
on the computer to verify that it In declining to analogize a computer recollection of the circumstances
would operate. She then transferred to a mere storage container, the surrounding the search;
the laptop to a second CBP officer court justified its actions using a • characterized Arnold as “di-
who noticed numerous icons and broad range of privacy interests: sheveled” and then admitted the
folders on the display screen, includ- term came not from her but from
ing two folders labeled “Kodak pic- “People keep all types of per- government’s counsel; and
tures” and “Kodak memories.” (The sonal information on comput- • selected Arnold because “he did
term “Kodak memories” is part of ers, including diaries, personal not become agitated when she
popular North American parlance letters, medical information, pulled him aside for secondary
and appears in testimonials by photos, and financial records. questioning”—in her view, US
Americans and Canadians on Kodak Attorneys’ computers may citizens who are so selected “typi-
Web sites, such as www.kodak contain confidential client cally become agitated and mad.”6
gallery.com/oprah_bigadventure/ information. Reporters’ com-
and wwwcaen.kodak.com/CA/en/ puters may contain infor- Further compromising the testi-
motion/publication/onFilm/jcLab mation about confidential mony, Officer Peng’s suspicions con-
recqueQA.jhtml.) Purporting to act sources or story leads. Inven- sisted of a one-page memo she wrote
on those allegedly suspicious labels,
the CBP officers clicked open the
folders to view the contents. Among
the images, they found one of two
naked adult women.
With this discovery, Immigration
and Customs Enforcement (ICE)
special agents interrogated Arnold for
several hours about his laptop’s con-
tents. They expanded the search and
found numerous images of what they
believed to be child pornography.
The ICE agents then seized Arnold’s
computer equipment and released
him. Two weeks later, federal agents
obtained a warrant to search the lap-
top and storage devices and found ad-
ditional images.
The government indicted
Arnold for possession and trans-
portation of child pornography.
Arnold moved to suppress the evi-
dence, claiming the CBP’s search
and seizure of his computer equip-

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 73

 Privacy Interests
nearly a year after the search, at the
government’s request and based, in
part, on recollections by others.
Most relevant for future cases,
At one level, laptops and computer devices
simply store data; at another level, that data
represents our intimate thoughts, hopes,
dreams and desires.
the court reasoned that, although
not as invasive as a body cavity
search, “the search of one’s private
and valuable personal information
stored on a hard drive or other elec-
tronic storage device can be just as
much, if not more, of an intrusion
into the dignity and privacy inter-
ests of a person.”6 The court sup-
ported its proposition with the
following analogy:
“This is because electronic
storage devices function as an
extension of our own mem-
ory. … Therefore, govern-
ment intrusions into the
mind—specifically those that
would cause fear or appre-
hension in a reasonable per-
son—are no less deserving of
Fourth Amendment scrutiny
than intrusions that are physi-
cal in nature.”6
An analogy between human
memory and computer memory is
inaccurate and likely misleading for
future judicial consideration, but the
court was on to something. Because
people entrust intimate, sensitive
data to laptops, a government’s
search of a laptop deserves to be
equated to searching a person’s
thoughts and thought processes, and
that clearly does amount to an inva-
sive search. The court didn’t advo-
cate permissive relaxation of border
protection—only that a reasonable
ground for suspicion exist if the gov-
ernment wishes to conduct an inva-
74 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
sive search of a laptop without first
obtaining a warrant.
A further aspect, not before the
court in this case, is the plausible sce-
nario of Arnold’s having encrypted
all data on his hard drive (except for
the file folders visible on the desk-
top). The CBP officers would have
seen nothing when they clicked on
the desktop icons. Could CBP have
attempted, with or without a war-
rant, to compel Arnold to disclose
the password? The answer would
probably depend on whether he had
memorized the password or written
it down on paper in his possession or
in a unencrypted document stored
on his laptop. Arnold could refuse to
disclose what he had memorized,
and probably justify it with a Fifth
Amendment right against self-
incrimination. If the password were
on paper in his possession or stored in
a laptop file, the reasoning in Arnold
suggests that the court might not re-
quire a warrant to search him for the
paper, but would still require that
CBP have a particularized suspicion
(or a warrant) to search the unen-
crypted laptop files for the password
because by encrypting the data Ar-
nold would demonstrate both a sub-
jectively and objectively reasonable
expectation of privacy. Moreover, it’s
doubtful that CBP could legally
compel Arnold to assist in their
search by identifying the paper or the
file containing the password.
Northern perspective
To put a discussion of the American
positions in perspective, it might be
useful to consider the same issue out-
side the US. The Supreme Court of
Canada took the opportunity to rule
on the constitutionality of warrantless
customs searches in R. v. Simmons.7
Writing in regard to section 98 of the
Customs Act, dealing with searches
of the person, the Court noted:
“The dominant theme unit-
ing [the American] cases is
that border searches lacking
prior authorization and based
on a standard lower than
probable cause are justified by
the national interests of sover-
eign states in preventing the
entry of undesirable persons
and prohibited goods, and in
protecting tariff revenue.
These important state inter-
ests, combined with the
individual’s lowered expec-
tation of privacy at an inter-
national border render
border searches reasonable
under the Fourth Amend-
ment. In my view, the state
interests enunciated through-
out the American jurispru-
dence that are deemed to
make border searches reason-
able are no different in princi-
ple from the state interests
which are at stake in a Canadian
customs search for illegal nar-
cotics. National self-protection
becomes a compelling com-
ponent in the calculus….
Consequently, travelers seek-
ing to cross national bound-
aries fully expect to be subject
to a screening process.”7
Although the Canadian Supreme
Court didn’t go so far as to hold that
searches at the border are reasonable
by the very fact that they occur at the
border, it did accept that a lower
threshold, including search without
a warrant, does not offend section 8
of the Canadian Charter of Rights
and Freedoms (a provision compa-
rable to the US Fourth Amend-
ment). When reasonable suspicion
has been formulated, both objec-
tively and subjectively, the search
may be more intrusive.

In Simmons, the Court also held
that personal searches will engage
the right to counsel in order to en-
sure that the person being searched
has the procedural protections
afforded under the law and that
Canadian customs officers have rea-
sonable grounds. (The denial of the
right to retain and instruct counsel
combined with customs officers’
failure to properly inform the
detainee of her rights under the
Customs Act made the search un-
reasonable in Simmons.) Similarly,
the Court held that, although the
authority provided in the Customs
Act to search a person or their goods
at the border doesn’t offend the
Charter, the way in which the
search is carried out can. For highly
invasive searches, additional protec-
tions will be required:
“Searches of the third or bod-
ily cavity type may raise en-
tirely different constitutional
issues, for it is obvious that the
greater the intrusion, the
greater must be the justifica-
tion and the greater the degree
of constitutional protection.”7
Canadian courts have yet to
address personal information con-
tained on a person’s laptop com-
puter. If they take the same position
as the US District Court in Arnold,
such searches might require greater
justification and benefit from greater
constitutional protection.
A t one level, laptops and com-
puter devices simply store data;
at another level, that data represents
our intimate thoughts, hopes, dreams,
and desires. When new technologies
and new means of communication
enhance our ability to express our-
selves, people commonly explore
them with insufficient regard to the
privacy risks involved. That doesn’t
mean abandoning privacy any more
than someone who forgets to look
both ways before crossing a street in-
tends to sacrifice their safety. In a
world in which threats of terrorism
are real and continue to proliferate, a
government seeking to defeat them
must try to deprive the perpetrators
of their most useful tools. At border
“ports of entry,” government agents
search for such tools and evidence
that can provide early warning of
emerging and imminent threats. If
Arnold withstands appeal, the case
provides a cogent reminder that
privacy can be protected against ill-
grounded—and thus unreason-
able—searches and seizures without
compromising national security.
The treatment of personal and com-
mercial information on laptops
should not be linked to the device’s
location but rather to the sensitivity
of the information it contains. As the
Arnold court observed, “as a search
becomes more intrusive, it must be
justified by a correspondingly higher
level of suspicion of wrongdoing.”6
Given that searching a laptop’s con-
tents approximates a kind of delayed
mind reading, the privacy interests at
stake are among those most deserv-
ing protection.
References
1. R.L. Trope and E.M. Power, “Les-
sons for Laptops from the 18th
Century,” IEEE Security & Privacy,
vol. 4, no. 4, 2006, pp. 64–68.
2. United States v. Flores-Montano, US
Reports, vol. 541, 2004, p.149.
3. United States v. Ramsey, US Reports,
vol. 431, 1977, p. 606.
4. United States v. Guadalupe-Garza, Fed-
eral Supplement, 2nd Series, vol. 421,
1970, p. 876 (9th Circuit Court).
5. United States. v. Rodriquez, Federal Sup-
plement, 2nd Series, vol. 592, 1979, p.
553–556 (9th Circuit Court).
6. United States v. Arnold, Federal Sup-
plement, 2nd Series, case no. 05-
00772, 02 Oct. 2006 (US District
Court, Central District of Calif.).
7. Regina v. Simmons, Supreme Court
Reports, vol. 2, 1988 (Canada).
E. Michael Power is a partner in the
Ottawa, Canada, office of Gowling
www.computer.org/security/
Privacy Interests
LaFleur Henderson LLP, where he
provides strategies and legal advice on
technology, privacy, regulatory, and in-
formation management issues. He has
a BA, an MBA, and an LLB from Dal-
housie University, Canada. Power is a
coauthor (with Trope) of Sailing in Dan-
gerous Waters: A Director’s Guide to
Data Governance (American Bar Asso-
ciation, 2005). Contact him at michael.
power@gowlings.com.
Roland L. Trope is a partner in the New
York City office of Trope and Schramm
LLP and an adjunct professor in the
Department of Law at the US Military
Academy. He has a BA in political science
from the University of Southern Califor-
nia, a BA and an MA in English language
and literature from Oxford University,
and a JD from Yale Law School. Trope
coauthored the treatise Checkpoints in
Cyberspace: Best Practices for Averting
Liability in Cross-Border Transactions
(American Bar Association, 2005). Con-
tact him at roland.trope@verizon.net.
Jonathan Gilhen is a student-at-law at
Gowling Lafleur Henderson LLP. His
research interests include competition
and antitrust law, corporate finance and
securities regulation, regulation of finan-
cial institutions, and corporate taxation.
He has a BA in economics from Saint
Mary’s University in Halifax, Canada, an
MA in economics from the University of
Victoria, and an LLB. from the University
of Ottawa. Contact him at jonathan.
gilhen@gowlings.com.
IEEE Distributed Systems Online
brings you peer-reviewed articles, detailed
tutorials, expert-managed topic areas, and
diverse departments covering the latest news
and developments in this fast-growing field.
Log on for free access to such topic areas as
Security • Grid Computing • Mobile &
Pervasive • Cluster Computing •
Games & Simulation • Peer-to-Peer
and More!
To receive monthly updates, email
dsonline@computer.org
http://dsonline.computer.org
■ IEEE SECURITY & PRIVACY 75
 Crypto Corner
Editors: Peter Gutmann, pgut001@cs.auckland.ac.nz
David Naccache, david.naccache@ens.fr
Charles C. Palmer, ccpalmer@us.ibm.com

When Cryptographers
Turn Lead into Gold

A
t its core, a cryptographer’s job is to “transmu- that bind public keys to identities
only for those users who can au-
tate” trust: just as alchemists turn lead into gold, thenticate to the CA both their
identities and public-key ownership.
cryptographers transmutate trust in one or more Consequently, if a valid certificate
accompanies Bob’s public key, Alice
assumptions into trust in some other simpler and can be certain that the key she has is
Bob’s. At this point, Alice’s trust is
better-defined assumptions, the ones on which the security of further transmutated into trust that
the CA performs its job correctly
PATRICK P. complex monolithic systems rely. Be- the decryption of arbitrarily chosen and honestly.
TSANG cause we can enforce and verify the ciphertexts—can’t extract a single But should Alice trust the CA?
Dartmouth resulting assumptions’ validity more bit of information about the under- She might still be unhappy because
College easily, such transmutation makes those lying plaintext message from any she’s afraid that the CA could be
systems more secure at a higher as- ciphertext encrypted under Bob’s tricked into signing a certificate for
surance. Unlike alchemists, though, public encryption key. Alice can Eve, who pretends to own Bob’s
cryptographers have successfully con- therefore encrypt messages for Bob public key. Cryptographic zero-
structed some of the building blocks before sending them to him. knowledge and proof-of-knowledge
(such as public-key encryption and If we assume that the public key protocols can help here, but ulti-
digital signatures) that play a make-or- Alice used during encryption was mately cryptographers only trans-
break role in many of today’s security- indeed Bob’s, then the problem of mutate trust—they don’t create it.
critical infrastructures. how to communicate securely is At the end of the transformation
In this installment of Crypto solved—cryptographers turned Alice’s chain, we must find a root of trust
Corner, we’ll look at how cryptog- need to trust that some arbitrary sys- whose establishment we can verify
raphers transmutate trust, identify tem will magically provide message without cryptography, be it via tech-
some of the reasons why they some- confidentiality into trust that the nology, economics, laws and poli-
times fail, and investigate how they public key she used was Bob’s, cies, or a mix of these.
could do a better job. which is a much simpler and better-
defined assumption. Alice doesn’t How well have our
The transmutation need to cross her fingers anymore trust alchemists done?
of trust after the transmutation. If a sophomore alchemist could
The idea of cryptographers as trust Or does she? Can she really trust blow up her neighborhood while
alchemists is best illustrated with a that she’s using Bob’s public key? trying to turn lead into gold, you
simple scenario. Let’s say that Alice Let’s summon our trust alchemists might also wonder if cryptographers
wants to deliver messages to Bob se- again, who this time conjure up a se- have done a good job in securing
cretly over an insecure communica- cure digital signature scheme. Se- systems. The answer “not quite”
tion channel wherein adversaries cure digital signatures must be probably won’t surprise you. As we
might passively listen or even ac- unforgeable: without the knowl- all know, system security is a difficult
tively drop and inject messages. To edge of Carol’s private signing key, problem to solve because of its in-
help Alice, cryptographers have no adversary can forge a signature on herent lack of robustness—a system
constructed secure public-key en- Carol’s behalf. is only as secure as its weakest link, so
cryption schemes, the confidential- Now let’s assume the existence of even a slight flaw in the transmuta-
ity property of which guarantees the a third party—called the certifica- tion can break an entire system’s se-
following: without knowledge of tion authority (CA) in public-key curity, rendering the transmutation a
Bob’s private decryption key, adver- infrastructure (PKI) nomencla- total failure. Let’s look at which in-
saries—even those who can study ture—who digitally signs certificates gredients are currently missing in the

76 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY
 Crypto Corner

recipe for trust transmutation, why dent of the secret input’s value—for gramming languages, and compilers
they’re missing, and how our trust example, by padding dummy opera- to the software implementation.
alchemists can do a better job. tions into the algorithm. However,
timing attacks still exist and can Provable but
Side channels strike in new and surprising ways, uninstantiatable security
Advances in provable security in the such as when Hash functions are a good example of
past 20 years have resulted in a quan- how cryptographic protocols that are
tum leap in the security assurance of • dummy operations get optimized provably secure in research papers
many cryptographic protocols. Cryp- away by “smart” compilers, might fall short of finding an instanti-
tographers have moved from the “if- • adversaries launch timing attacks ation in the real world, thus leaving
cracked-then-fix-and-repeat” targeted at Secure Sockets Layer doubts about the security of their im-
construction paradigm to emphasiz- (SSL) Web servers from any re- plementation. A vital building block
ing precise formalisms of security mote location,1 in many cryptographic protocols is
models that capture powerful and yet • interkeystroke timing reveals a the use of collision-resistant hash
realistic adversarial capabilities. password as it’s typed in a Secure functions, whose existence had been
Today’s security formalisms, Shell (SSH) session,2 or taken for granted until recently when
however, still mostly focus on the • cache hit-and-miss attacks3 and researchers started realizing that such
protocol level. Perhaps this is in- branch-prediction attacks4 exploit functions had become an endangered
evitable because the abstraction that the underlying architecture’s effi- species. (A nail in MD5’s coffin came
cryptographers typically use— ciency features. last year, when anyone could find a
namely, modeling Alice and Bob as new collision in tens of seconds on a
Turing machines or probabilistic These scenarios suggest that trust al- laptop. Finding a SHA-1 collision still
polynomial-time algorithms—pre- chemists who think only at the pro- takes 268 steps today, although most
vents them from governing, let alone tocol level can’t defend against people believe it’s only a matter of
reasoning, how the algorithms they side-channel attacks. Rather, if time before the SHA family leaves us
devised should run as physical oper- cryptographers want to successfully as well. Two earlier Crypto Corner
ations in the machines we use today. secure systems through trust trans- installments covered this issue com-
Side channels are adversarial ca- mutation, their solutions must take prehensively.)5,6 The consequence of
pabilities that a security model into account the whole spectrum of such an extinction will be devastat-
can’t capture because of the exis- the problem, from the underlying ing; many cryptographic protocols,
tence of implementation-specific architecture, operating system, pro- including most encryption and digi-
surface areas below the abstraction.
Timing information, power con-
sumption, and even the acoustic
waves generated during algorithm
execution are a few examples of po-
tential attack surfaces. Let’s look
more closely at timing attacks,
which exploit the trivial fact that it
takes an algorithm different amounts
of time to complete for different in-
puts. A timing profile of multiple
algorithm runs gives statistically cor-
related information about the input
to the algorithm. Here, an input
could be external (such as a private
decryption key) or internal (such as
the randomness used). In either case,
as long as the input isn’t supposed to
fall into an attacker’s hands, it’s a juicy
piece of information.
In theory, timing attacks are an
old and solved problem. All you have
to do is ensure that the time an algo-
rithm takes to complete is indepen-

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 77

 Crypto Corner
tal signature schemes in use today, are
proven secure under the assumption
that the underlying hash functions are
collision resistant. If these protocols
are instantiated with hash functions in
which it’s possible to find collisions,
we won’t know if they’re secure any-
more. In fact, Arjen Lenstra and his
colleague7 constructed two distinct
X.509 certificates whose hashes col-
lide to demonstrate that MD5 colli-
sions can violate the unforgeability
guarantee of digital signatures and
thus the principles underlying the
trust in PKI.
Another uninstantiability com-
monly found in cryptographic con-
structions is also related to hash
functions. We can prove a certain class
of cryptographic protocols’ security
under the so-called Random Oracle
Model (ROM), in which black-box
entities known as random oracles an-
swer queries with truly random but
consistent responses. Nonetheless,
no function behaves exactly the same
as a random oracle does in reality. As a
result, cryptographers suggest the use
of collision-resistant hash functions as
a substitute when implementing
these protocols. How secure these
implementations actually are, how-
ever, is uncertain because the use of
hash functions instead of random ora-
cles violates the premises in the
proofs. In fact, protocols exist that are
proven secure under ROM but are
shown to be insecure when we in-
stantiate the random oracles with
collision-resistant hash functions.8
Cryptographers continue to wage a
heated debate on the ROM’s merits:
one school of thought believes that
proving security in the ROM pro-
vides no practical security assurance,
whereas another believes that security
in the ROM can at least serve as a
good heuristic.
Provably secure cryptographic
protocols that aren’t instantiable are
like transmutation recipes that re-
quire magic beans. To solve the
problem, we must either find ways
to synthesize these magic beans (see
www.csrc.nist.gov/pki/HashWork
78 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
shop/index.html for an example) or
redesign the recipes so that they
don’t require magic, by, for instance,
constructing cryptographic proto-
cols whose security we can prove
without assuming random oracles.
A study of ciphers
In applied cryptography, multiple
professional disciplines such as math-
ematics, computer science, and
engineering converge into one com-
munity. Although cryptographers
communicate their ideas and argu-
ments into precise models, algo-
rithms, theorems, and proofs, people
outside this community tend to find
cryptography research papers as illeg-
ible as ciphertexts output from a se-
cure encryption. Few people are
willing to go beyond the threshold,
the consequence of which is twofold.
First, the language cryptogra-
phers speak is lost when it’s translated
into implementation languages; sys-
tem developers misunderstand it,
which routinely results in the inse-
cure realization of secure protocols.
As an example, Daniel Bleichen-
bacher forged “provably unforge-
able” RSA signatures thanks to a
flaw in the signature verification al-
gorithm’s implementation (www.
mail-archive.com/cryptography@
metzdowd.com/msg06537.html).
Such an error could have been pre-
vented had the developer realized
the subtlety of cryptographic proto-
col security and had thus put extra
effort into ensuring the implemen-
tation correctly preserved the se-
mantics of every symbol and
statement in the protocols.
Second, security proofs in cryp-
tography papers are so esoteric that
few people actually read them. The
fact that it took seven years before
anyone found a flaw in the proof for
the RSA-OAEP encryption9 sur-
prised everyone (at the time, this en-
cryption helped secure e-commerce
transactions). That only the experts
need to understand and review cryp-
tography is an unfortunate miscon-
ception: cryptography has a direct
impact on everyone and everything,
from buying a book online to de-
fending a nation. It deserves curious
and skeptical eyes. A utopia we can
only dream of today—but should
strive hard to achieve—is a world in
which your mother says she prefers
the Cramer-Shoup cryptosystem10
over RSA-OAEP because the secu-
rity of the former doesn’t rely on ran-
dom oracles.
Randomness
Randomness is a must-have ingredi-
ent for trust transmutation—it’s a
crucial, yet delicate resource for most
cryptographic protocols. Without
the ability to pick elements from cer-
tain sets uniformly at random, there
simply wouldn’t be secure public-
key encryption or digital signatures.
Consider an extreme situation in
which an adversary knows the entire
randomness used to generate a DSA
signature—he or she could easily re-
cover the private key from the signa-
ture and start forging signatures
universally. The fact that DSA signa-
tures are provably unforgeable no
longer guarantees the impossibility of
forgeries because the assumption
made in the security model about the
availability of a true random source
whose process is unobservable to
anyone other than the signing entity
ceases to hold.
Despite its importance, few peo-
ple worry about this ingredient’s
quality and supply—is the random-
ness we get from a random source
truly random, and could we ever run
out of it? Most PC architectures today
aren’t equipped with a hardware ran-
dom number generator, which
makes it difficult to securely provide
randomness to cryptographic soft-
ware running on these machines.
Linux, for example, relies on extract-
ing randomness from the entropy
gathered from random system events
such as user input, disk access, and
network traffic. Nevertheless, ran-
domness could be exhausted before
it’s replenished, especially on systems
with few entropy sources, such as net-

work routers and sensor nodes that
don’t have user inputs or disks. Under
such circumstances, the running
process would either have to halt until
enough randomness becomes avail-
able or use insecure randomness.
Y ogi Berra once said, “In theory,
there is no difference between
theory and practice, but in practice,
there is.” As we’ve seen in this article,
although we’ve had some initial suc-
cess in transmutating trust using cryp-
tography at a theoretical level, we’re
not quite there yet in terms of making
system security bulletproof in prac-
tice. To close that gap, we must incor-
porate the hardware architecture into
our design and model, develop new
skills to formalize implementation-
specific adversarial capabilities, take
into account the underlying hard-
ware’s features and weaknesses, and, if
beneficial, augment the architecture
with security-enhancing mecha-
nisms. Moreover, we must make
cryptography more accessible so that
system security can benefit from the
awareness of a bigger community, in-
cluding systems designers, applica-
tion developers, hardware architects,
and end users. I’m not so much inter-
ested in being able to turn lead into
gold—not only because I’m not con-
vinced it will ever be possible, but also
because of the insecurity I would feel
once I became too rich. Rather, I’m
confident in, and look forward to,
trust alchemists doing an increasingly
better job of making the world a
more secure and better place to live
for everybody.
References
1. D. Brumley and D. Boneh,
“Remote Timing Attacks Are
Practical,” Computer Networks, vol.
48, no. 5, 2005, pp. 701–716.
2. D. Xiaodong Song, D. Wagner, and
X. Tian, “Timing Analysis of Key-
strokes and Timing Attacks on
SSH,” Proc. 10th Usenix Security
Symp., Usenix Assoc., 2001, pp.
337–352.
Crypto Corner
3. D. Page, Theoretical Use of Cache Springer-Verlag, 2005, pp. 267–279.
Memory as a Cryptanalytic Side 8. R. Canetti, O. Goldreich, and S.
Channel, tech. report CSTR-02- Halevi, “The Random Oracle
003, Dept. Computer Science, Methodology, Revisited,” J. ACM,
Univ. of Bristol, June 2002. vol. 51, no. 4, 2004, pp. 557–594.
4. O. Aciiçmez, C. Kaya Koç, and J.-P. 9. V. Shoup, “OAEP Reconsidered,”
Seifert Onur, “Predicting Secret CRYPTO, LNCS 2139, J. Kilian,
Keys via Branch Prediction,” Cryp- ed., Springer-Verlag, 2001, pp.
tographers’ Track at RSA 2006 (CT-
RSA 06), LNCS 4377, M. Abe, ed.,
Springer-Verlag, 2006, pp. 225–242.
239–259.
10. R. Cramer and V. Shoup, “A Prac-
tical Public Key Cryptosystem Prov-
5. P. Gutmann et al., “When Hashes ably Secure against Adaptive Chosen
Collide,” IEEE Security & Privacy, Ciphertext Attack,” CRYPTO,
vol. 3, no. 3, 2005, pp. 68–71. LNCS 1462, H. Krawczyk, ed.,
6. J.-S. Coron, “What is Cryptogra- Springer-Verlag, 1998, pp. 13–25.
phy?” IEEE Security & Privacy, vol.
4, no. 1, 2006, pp. 70–73. Patrick P. Tsang is a PhD student at
7. A. Lenstra and B. de Weger, “On the Dartmouth College. His research inter-
ests include applied cryptography, secu-
Possibility of Constructing Mean- rity and privacy, and trusted computing.
ingful Hash Collisions for Public Tsang has an MPhil in information engi-
Keys,” 10th Australasian Conf. Infor- neering from the Chinese University of
Hong Kong. He’s a member of the Inter-
mation Security and Privacy (ACISP
national Association for Cryptologic
05), LNCS 3574, C. Boyd and J. Research (IACR). Contact him at patrick@
Manuel González Nieto, eds., cs.dartmouth.edu.
The magazine that helps
scientists to apply high-end
software in their research!
Top-Flight Departments in Each Issue!
• Book Reviews • Technology
• Computer • Visualization
Simulations Corner
• Education • Your Homework
$45
print & online
• Scientific
Programming
Assignment
Peer- Reviewed Theme & Feature Articles
2 0 0 7 Jan/Feb Anatomic Rendering & Visualization
Mar/Apr Stochastic Modeling of Complex Systems
May/Jun Python: Batteries Included
Jul/Aug New Directions
Sep/Oct High-Performance Computing
Defense Applications
Nov/Dec Computing in Combinatorics
Subscribe to CiSE online at http://cise.aip.org/cise and www.computer.org/cise
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 79
 Secure Systems
Editor: S.W. Smith, sws@cs.dartmouth.edu

A Case (Study) For Usability in

Secure Email Communication

A
s a network security researcher, I find it very dis- hold Alice to her original contract by
proving that the signature he pos-
appointing that most users can’t, or simply don’t, sesses was created before Alice pub-
lished her key—perhaps by using a
secure their everyday Internet communications. time-stamping service2 or an online
notary—Alice can still claim that she
For good reason, usability in security has received didn’t know her key was stolen.
More sophisticated protocols for
a fair deal of attention in the past few years (see the September nonrepudiation are needed, but as it
now stands with standard S/MIME,
APU KAPADIA 2004 special issue on this topic1). To realized that, currently, everyday nonrepudiation for casual email users
Dartmouth push the issue further, I decided to users seldom need to do so, as we doesn’t work in practice.
College initiate my own informal case study will see if we examine email signa-
on the usability and practical rele- tures more closely. Integrity
vance of standard security mecha- For any message, Alice can use Forging email messages on today’s In-
nisms for email communication. her private key to generate a crypto- ternet is surprisingly easy, and forg-
I focused my attention on avail- graphic package that a recipient can eries such as phishing emails are a
able public-key cryptography tech- verify only by using her public key direct threat to everyday users. In the-
niques for digitally signing and and the original message. This pack- ory, if messages are digitally signed,
encrypting email. My first step was age is called a digital signature and recipients can reject those with
to establish a public–private key pair provides two basic properties: non- spoofed “From” addresses because
to use with email. I chose to use Se- repudiation and integrity. their signatures won’t be valid—that
cure/Multipurpose Internet Mail is, only Paypal can sign messages that
Extensions (S/MIME), a standard for Nonrepudiation appear to come from paypal.com.
signing and encrypting email, be- Nonrepudiation is the idea that, in Digital signatures also provide protec-
cause it’s already supported by popu- theory, a signer such as Alice can’t tion against adversaries who modify
lar email clients such as Apple Mail, later deny that she signed the mes- parts of the message in transit,
Outlook Express, and Mozilla’s sage. For example, occasionally I although I would argue that such
Thunderbird. Unlike S/MIME, I submit reviews for conference papers email modifications present very lit-
found that Pretty Good Privacy over email. I could digitally sign my tle threat to everyday users—for them,
(PGP) and the GNU Privacy Guard messages to claim responsibility for digital signatures’ main utility is in
(GPG) were unusable with nontech- my words. But as any security re- countering forged sender addresses.
nical correspondents because it re- searcher would be quick to point In practice, however, digital signa-
quired them to install additional out, digital signatures’ nonrepudia- tures are a weak line of defense. Phish-
software. S/MIME, it seemed, was bility is just an illusion. Alice can al- ers can use cleverly crafted email
the better solution for these “every- ways claim that someone stole her addresses such as customer-service@
day users,” for whom the concepts of private key and that the signature is a paypal-help.com to trick users into
public-key infrastructure (PKI), PGP, forgery. And if that’s not enough, believing that they’re corresponding
certificates, keys, and so on remain Alice can publish her key in The New with Paypal. Because phishers can le-
elusive. Additionally, I decided to get York Times, letting potentially any- gitimately own a domain such as pay-
my public key certified by Thawte body sign a message using it. In such pal-help.com, a phisher can obtain a
(www.thawte.com), an online cer- situations, Alice can be penalized for certificate and generate emails from
tificate authority (CA). negligence or irresponsible behavior, that domain that have valid signatures
but she can’t be held responsible for (this is just a hypothetical example, but
Digital signatures the contents of messages signed with at the time of writing, paypal-
After months of signing email, I’ve her private key. Even if Bob tries to help.com was registered under a for-

80 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY
 Secure Systems

eign mailing address). Any mecha-
nism that combats phishing must look
beyond the integrity protection that
digital signatures provide. Given that
most email that users receive is un-
signed, users routinely verify a mes-
sage’s integrity based on its contents
and context. In fact, I find myself ver-
ifying messages’ integrity based on
their overall content, even when they
are digitally signed. For the lack of a
better term, I call this form of in-
tegrity “semantic integrity,” in con-
trast to the standard notion of
(syntactic) integrity that digital signa-
tures provide. When corresponding
with familiar people, verifying the se-
mantic integrity of email messages is
surprisingly easy—digitally signed or
not, strange text from a friend that
contains an attached virus looks suspi-
cious. I routinely ignore signatures
from family, friends, and acquain-
tances simply because I’m confident
that I can sniff out forgeries.
At this point I will re-emphasize
my focus on everyday users. Certainly,
defense contractors, network admin-
istrators, and so on are well advised to
digitally sign messages to correspon-
dents who expect them. You can in-
struct employees to reject any message
from the security officer without a
valid signature—certain job functions
rely on baseline security mechanisms
for which you can provide training.
For everyday users, however, using
digital signatures to verify messages’
integrity is both overkill and prone to
error, the former because using signa-
tures for detecting alterations doesn’t
address a tangible threat, and the latter
because telling everyday users to “en-
sure that the signature is valid” to de-
tect forgeries is a misguided heuristic.
Focusing on tools that will help them
verify semantic integrity, instead, is
more promising.
tion, although anecdotal, has made a
lasting impact on my use of signatures
and highlights the need for more re-
search on usability in security.
By default, some email clients at-
tempt to digitally sign replies to signed
messages. While responding to my
signed email, a correspondent who
works for the military was told to “in-
sert cryptocard.” Because the corre-
spondent was not familiar with digital
signatures, I received a reply with a
suspicious tone (whether intended or
not, this is how I interpreted it). With
the prospect of a potentially peeved
military official, I found myself
obliged to explain that I was not trying
to do anything sneaky with govern-
ment computers, and that the email
client was the culprit with its auto-
mated behavior. A couple of test
emails, with and without signatures,
convinced the correspondent of my
theory—that the email client was in-
deed trying to automatically sign
replies to my signed messages.
In a separate incident, another
correspondent, also unfamiliar with
PKI, was facing problems after en-
countering a certificate signed by an
untrusted CA. After clicking on
“examine certificate,” and a stray
click later, my certificate was pre-
sented for examination. The email
client automatically obtained this
certificate from earlier messages I
had signed. From my correspon-
dent’s viewpoint, however, the
problem with connecting to an un-
trusted email server was somehow
linked to my name. Again, I found
myself obliged to explain that I
wasn’t trying to do anything sneaky
with my correspondent’s email
client. These incidents have taught
me an important lesson: sign your
messages only to people who under-
stand the concept. Until more usable
mechanisms are integrated into pop-
ular email clients, signatures using
S/MIME should remain in the do-
main of “power users.”
Encryption and the key
distribution problem
Now, more than ever, the privacy of
our communications is at risk. The
government is increasingly inter-
ested in our conversations, and in an
open system such as the Internet, we
must take added measures to ensure
our privacy rights. With the confi-

Incrimination
Given that the two most important
properties of digital signatures don’t
seem useful in practice, why might
everyday users continue to sign
email? The property of incrimina-

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 81

 Secure Systems
dentiality of my electronic conversa-
tions in mind, I convinced some of
my research colleagues to encrypt
their email conversations with me.
By pre-installing third-party CA certificates
into email clients without rigorous auditing
procedures, vendors are breaking the trust
model required for PKI to be successful.
While exchanging public keys, the
most important step is to verify that a
man-in-the-middle isn’t subverting
your exchange. If we assume that an
adversary can control our conversa-
tions, we must verify the exchanged
public keys’ authenticity.
Charlie, a man-in-the-middle,
can pretend to be Bob with respect
to Alice and Alice with respect to
Bob. Alice and Bob communicate
“securely,” except that they’re both
communicating through Charlie
without realizing that he’s decrypt-
ing and re-encrypting their mes-
sages. The most secure way for Alice
and Bob to verify their keys’ authen-
ticity is to do so in person; this, how-
ever, is impractical, giving rise to the
key-distribution problem—how can
users distribute their public keys to
other parties reliably? The PKI
world has developed two solutions:
either rely on a trusted third party (or
a more elaborate network of trusted
third parties) such as Thawte or
VeriSign (www.verisign.com) to
certify that your correspondent’s
public key is bound to his or her
identity, or verify the authenticity
yourself by checking the public key’s
fingerprints through an out-of-band
(OOB) channel—that is, by a sepa-
rate means of communication.
Third-party “trust”
Verifying the authenticity of keys
with my correspondents was surpris-
ingly error-prone. Let’s analyze the
PKI solution that relies on CAs first.
If Alice’s public key is certified (digi-
82 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
tally signed) by a CA that Bob trusts,
then Bob will accept Alice’s certifi-
cate as being authentic. If Alice’s key
is certified by a CA that’s not on
Bob’s trusted list, Bob can try to find
a trusted path to Alice’s certificate by
starting at a CA that he does trust.
Let’s say that Bob trusts only CA1 and
encounters Alice’s certificate signed
by CA3. Bob can try to find a chain
of trust in which CA1 certifies CA2,
who in turn certifies CA3 (certificate
chains can be much longer in prac-
tice). This certificate chain lets Bob
establish a path of trust to Alice’s cer-
tificate, even though he doesn’t ex-
plicitly trust CA3. PKI proposes
meshes of CAs established by certifi-
cation relationships. Meshes can also
include hierarchies of higher-level
CAs certifying lower-level CAs and
cross-certification authorities which
can bridge trust hierarchies into a
mesh to aid in building trust paths.
Although this approach can pro-
vide a high level of assurance in en-
terprise-level communications, it has
a few limitations when applied to
email exchanges between everyday
users. Mainly at fault is the list of
“trusted” CAs that the email client’s
software vendor has pre-installed. A
colleague of mine, Scott Rea, calls
this a list of “third parties” as opposed
to a list of “trusted third parties” be-
cause this list doesn’t correspond to
the set of CAs that the email client’s
users trust. After all, I chose not to
get my public key certified from an
authority that I had never heard of
(and hence didn’t trust), but rather
had it certified by Thawte. My cor-
respondents, however, don’t know
my trusted CA a priori. A powerful
man-in-the-middle attack could in-
deed create a bogus certificate for my
identity, certified by a malicious CA
that I don’t trust, but that is on the list
of installed third-party CAs. Because
the S/MIME email client would
trust the certificate, were my col-
leagues accepting a fake certificate
signed by another CA or were they
accepting my Thawte certificate?
Clearly, users must first trust the
CAs installed in their email clients.
Second, if Alice and Bob are ex-
changing keys, they should use a CA
that they both trust. Absent a com-
mon trusted CA, the just-men-
tioned man-in-the-middle attack is
still possible, with or without certifi-
cate chains. PKI has been plagued by
its end-points—by pre-installing
third-party CA certificates into
email clients without rigorous audit-
ing procedures, vendors are breaking
the trust model required for PKI to
be successful.
Now, consider enterprise sys-
tems, in which organizations can
make rigorous policy decisions
about a CA’s certification proce-
dures and thereby outsource the
key management functions to a
trusted CA. They can also make
rigorous policy decisions regarding
valid trust paths to other CAs. For
example, the Higher Education
Bridge Certification Authority
(HEBCA) has a stringent process of
assigning levels of assurance (LOA) to
CAs that are part of the bridge.
Higher education organizations
can then trust HEBCA, and the or-
ganizations that are part of HEBCA
can trust each other’s certificates. In
other words, HEBCA “bridges”
trust between different organiza-
tions operating under their own
PKIs by certifying their CAs’ prac-
tices. Training employees within an
organization to recognize valid cer-
tificates is feasible because the orga-
nization has a financial incentive to
do so. Everyday users, however,
don’t have the time or motivation
for rigorous bookkeeping about
various CAs’ certification proce-
dures. CA-certified keys and

trusted paths are less meaningful if
users don’t understand the certify-
ing CA’s procedures and are willing
to accept any certificate that their
email client trusts. (Note, however,
that PKI can be quite successful as a
means for an enterprise-level or-
ganzation to authenticate everyday
users—the organization can have
rigorous policies about which CA’s
certificates it should accept, with-
out including everyday users in
these trust decisions.)
As I’ve argued, exchanging keys
using current implementations of
S/MIME is risky for everyday users
because their trust in their email
clients is misplaced. We must take a
long-term approach toward building
usable key-management methods and
educating everyday users about trust-
ing CAs and establishing a common
root of trust with their correspon-
dents. An independent organization
such as HEBCA can audit CAs care-
fully and help establish a common
root of trust. Users and email client
vendors can then be instructed to trust
only CAs with the auditing organiza-
tion’s approval. In the short-term,
however, because most everyday users
don’t have mutually trusted CAs, they
should use the second solution, fin-
gerprint verification, to foil man-in-
the-middle attacks.
Fingerprint verification
A fingerprint is a secure hash of the
public key and is a smaller, digested
form. Verifying that the exchanged
key’s fingerprint matches the origi-
nal key’s fingerprint is a much faster
way to verify the key’s authenticity.
The recently proposed concept of
key continuity management (KCM)3,4 is
an emerging alternative to the CA-
based approach. KCM posits that
once Bob has verified a key’s finger-
prints, he can be sure that the key he
uses for encryption is the same one
he’s verified in the past. Users needn’t
rely on an elaborate network of CAs
to certify keys. As with SSH, users of
email clients are assumed to verify a
newly observed key’s fingerprint, af-
ter which key continuity gives the
user a sense of security. This ap-
proach has limitations, however:
what can Alice do if her key is com-
promised? In a CA-based approach,
before using Alice’s key to secure
communications, Bob can check the
CA’s revocation list or use the Online
Certificate Status Protocol (OCSP)
to ensure that it hasn’t been compro-
mised. KCM, however, relies on
Alice informing all her correspon-
dents that her key has been compro-
mised. KCM proponents argue that
the added benefit of an infrastruc-
tureless approach outweighs the re-
duction in security from potentially
compromised keys. If users verify
fingerprints often enough, they can
limit the amount of damage a com-
promised key causes.
This brings us to one final ques-
tion: how can users verify a key’s fin-
gerprints reliably? One option is to
verify fingerprints for email over IM
and fingerprints for IM over email.
However, this approach still won’t
protect us against motivated adver-
saries (or our employers!) who can
intercept both communication lines
and subvert our attempted OOB
fingerprint verification.
Exchanging SMS messages is a
viable option5 because the mobile
phone network is clearly separated
from our organizations’ networks
(or are they?). After hearing about
the purported collaboration be-
tween the NSA and AT&T, how-
ever, relying on phone companies
to deliver electronic fingerprints
also seems risky against capable ad-
versaries. In the end, if you can’t
In the end, if you can’t verify fingerprints
in person, it seems safest to verify them over
the phone.
verify fingerprints in person, it
seems safest to verify them over the
phone. This is the standard method
of fingerprint verification in voice-
www.computer.org/security/
Secure Systems
over-IP (VoIP) services such as
Philip Zimmermann’s Zfone (www.
philzimmermann.com/EN/zfone/),
given that it’s very difficult for a
man-in-the-middle to subvert a
voice conversation in real time.
Additionally, humans can easily
verify the semantic integrity of a
voice conversation with a known
correspondent because a man-in-
the-middle would have trouble im-
personating your correspondent’s
voice. (Caveat: humans are poor at
verifying the semantic integrity of
conversations with unknown cor-
respondents, a weakness that is ex-
ploited in social engineering attacks.)
It would be prudent, however, to
expect computers in the not-too-
distant future to be able to synthesize
voice in real time. A dedicated man-
in-the-middle could possibly re-
place the part of your conversation
related to fingerprint verification.
Soon, we will need more sophisti-
cated methods for verifying a remote
correspondent’s fingerprints, but
until then, relying on real-time voice
verification seems to be the best op-
tion. In my personal experience, my
correspondents seemed rather un-
comfortable with the “geekiness” of
reading random numbers over the
phone. However, with VoIP soft-
ware becoming more popular
among everyday users, a mechanism
to use the same verified keys for
email communications will be a
great solution to the problem of
OOB fingerprint verification.
Although neither the trusted
third-party nor fingerprint solutions
in their current forms seem suffi-
ciently secure for everyday users,
perhaps a hybrid approach is needed
in the short term. As I suggested
with CA-based PKI, everyday users
■ IEEE SECURITY & PRIVACY 83
 Secure Systems

should verify a key’s fingerprints.
Mechanisms developed for KCM
can bolster trust in CA-certified keys
and ensure that users verify finger-
prints to secure communication.
tribute-based annotations to help
users make better trust decisions
about their email communication.6
Until such usable mechanisms are
introduced into popular email
clients, however, proceed with cau-
tion and verify those fingerprints.
4. S.L. Garfinkel and R.C. Miller,
“Johnny 2: A User Test of Key Con-
tinuity Management with S/MIME
and Outlook Express,” Proc. Symp.
Usable Privacy and Security (SOUPS
05), ACM Press, 2005, pp 13–24.
5. A.J. Nicholson et al.,“LoKey:

T here are several barriers for every-

day users who wish to secure their
communications. S/MIME is sup-
ported by popular email clients, but
casual users are lulled into a false
sense of security; accepting “valid”
signatures without comprehending
the underlying trust assumptions or
being content with encrypted email
without being diligent about finger-
print verification highlights the
mismatch between the user’s expec-
tations and their communication’s
underlying security.
On the optimistic front, PKI
awareness is increasing—here at
Dartmouth College, all first-year
students are issued PKI tokens, and
research on usability for secure com-
munication is gaining momentum.
One promising approach uses at-
Acknowledgments
The author thanks Scott Rea for his insightful
comments and willingness to read multiple
drafts of this article. He also thanks Sean
Smith, Patrick Tsang, and Phoebe Wolfskill
for their helpful comments.
References
1. IEEE Security & Privacy, special issue
on usable security, vol. 2, no. 5, 2004.
2. S. Haber and W.S. Stornetta, “How
to Time-Stamp a Digital Docu-
ment,” J. Cryptology, vol. 3, no. 2,
1991, pp. 99–111.
3. P. Gutmann, “Why Isn’t the Inter-
net Secure Yet, Dammit,” Proc.
AusCERT Asia Pacific Information
Technology Security Conf., AusCERT,
May 2004; http://conference.aus
cert.org.au/conf 2004/.
Leveraging the SMS Network in
Decentralized, End-to-End Trust
Establishment, Proc. 4th Int’l Conf.
Pervasive Computing (Pervasive 06),
LNCS 3968, Springer-Verlag, pp.
202–219.
6. C. Masone and S.W. Smith,
“Towards Usefully Secure Email,”
IEEE Technology and Society Maga-
zine, to be published, Mar. 2007.
Apu Kapadia is a post-doctoral research
fellow at the Institute for Security Tech-
nology Studies, Dartmouth College. His
research interests include systems secu-
rity and privacy, and he is particularly
interested in anonymizing networks and
usable mechanisms for enhancing pri-
vacy. Kapadia has a PhD in computer sci-
ence from the University of Illinois at
Urbana-Champaign. He is a member of
the IEEE and the ACM. Contact him at
akapadia@cs.dartmouth.edu.

Advertising Sales Will Hamilton Email: steve@didierand

Representatives
Advertiser | Product Index
Mid Atlantic
March | April 2007 (product/recruitment)
Dawn Becker
Phone: +1 732 772 0160
Advertiser Page number Fax: +1 732 772 0164
Carnegie Mellon University 5 Email: db.ieeemedia@
ieee.org
CSINetSec 2007 Cover 4
John Wiley & Sons, Inc. Cover 2 New England (product)
Jody Estabrook
Nato 3 Phone: +1 978 244 0192
Fax: +1 978 244 0103
Email: je.ieeemedia@ieee.org
*Boldface denotes advertisements in this issue
New England (recruitment)
John Restchack
Phone: +1 212 419 7578
Fax: +1 212 419 7589
Advertising Personnel Email: j.restchack@ieee.org
Marion Delaney | IEEE Media, Advertising Director
Connecticut (product)
Phone: +1 415 863 4717 | Email: md.ieeemedia@ieee.org Stan Greenfield
Phone: +1 203 938 2418
Marian Anderson | Advertising Coordinator Fax: +1 203 938 3211
Email:
Phone: +1 714 821 8380 | Fax: +1 714 821 4010 greenco@optonline.net
Email: manderson@computer.org
Midwest (product)
Dave Jones
Sandy Brown Phone: +1 708 442 5633
IEEE Computer Society | Business Development Manager Fax: +1 708 442 7620
Phone: +1 714 821 8380 | Fax: +1 714 821 4010 Email: dj.ieeemedia@
ieee.org
Email: sb.ieeemedia@ieee.org
Phone: +1 269 381 2156
Fax: +1 269 381 2556
Email: wh.ieeemedia@
ieee.org
Joe DiNardo
Phone: +1 440 248 2456
Fax: +1 440 248 2594
Email: jd.ieeemedia@
ieee.org
Southeast (recruitment)
Thomas M. Flynn
Phone: +1 770 645 2944
Fax: +1 770 993 4423
Email:
flynntom@mindspring.com
Southeast (product)
Bill Holland
Phone: +1 770 435 6549
Fax: +1 770 435 0243
Email:
hollandwfh@yahoo.com
Midwest/Southwest
(recruitment)
Darcy Giovingo
Phone: +1 847 498-4520
Fax: +1 847 498-5911
Email: dg.ieeemedia@ieee.org
Southwest (product)
Steve Loerch
Phone: +1 847 498 4520
Fax: +1 847 498 5911
broderick.com
Northwest (product)
Peter D. Scott
Phone: +1 415 421-7950
Fax: +1 415 398-4156
Email: peterd@
pscottassoc.com
Southern CA (product)
Marshall Rubin
Phone: +1 818 888 2407
Fax: +1 818 888 4907
Email: mr.ieeemedia@
ieee.org
Northwest/Southern CA
(recruitment)
Tim Matteson
Phone: +1 310 836 4064
Fax: +1 310 836 4067
Email: tm.ieeemedia@
ieee.org
Japan
Tim Matteson
Phone: +1 310 836 4064
Fax: +1 310 836 4067
Email: tm.ieeemedia@
ieee.org
Europe (product)
Hilary Turnbull
Phone: +44 1875 825700
Fax: +44 1875 825701
Email: impress@impress
media.com

84 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007

 Digital Protection
Editors: Michael Lesk, lesk@acm.org
Martin R. Stytz, mstytz@att.net
Roland L. Trope, roland.trope@verizon.net

South Korea’s
Way to the Future

S
outh Korea is a country with advanced technology pany—with 600,000 customers M ICHAEL LESK
who can listen to 700,000 songs for Rutgers
and a great many users of it. Can we use it as a model roughly $5 per month (http:// University
investors.wmg.com/phoenix.zhtml
of what might happen as technology spreads? If so, ?c=182480&p=irol-newsArticle&
ID=854632&highlight=). This ra-
the news is pretty good for consumers: several online pidly growing service controls 60
percent of the South Korean online
services exist that are legal, with relatively generous terms. music market. Unlimited online ser-
vices for gaming and instant messag-
South Korea leads the world in ers, stored value cards, and full key- ing are also popular in South Korea.
access to broadband services; as of boards. South Korea’s ringtone mar- Vendors might have moved to this
early 2006, 83 percent of households ket alone is larger than its CD model because of the wildly publi-
had broadband, compared to market—ringtones brought in cized tragedy of a South Korean
roughly 45 percent in the US (www. US$336 million in 2004, for exam- teenager who ran up a $3,000 bill
websiteoptimization.com/bw/0607). ple. Consumers can buy unlimited playing online games and then com-
Not coincidentally, the country also music downloads for $5 per month mitted suicide (www.techdirt.com/
leads in the transition to digital or broadband service for $20 per articles/20061214/131943.shtml).
music sales via digital rights manage- month—and they’re about to have a But why did music copyright
ment (DRM) software. In fact, the new form of interoperability among holders agree to this system? Over-
past decade has seen South Korea’s music vendors. simplifying, the South Korean
music scene change dramatically. It recording industry is smaller and less
once had 8,000 music stores; now, it The new powerful than the telecommunica-
has 400—partly because of the Asian device choices tions industry. In fact, the music in-
financial crisis of the late 1990s, but Many South Koreans have had mo- dustry has agreed to some very bad
mostly due to the change in music bile phones that double as music bargains—at one point, it even ac-
distribution patterns. South Korea is players for two years (Apple’s up- cepted a percentage royalty on the
also the first country in which on- coming iPhone won’t be new tech- value of ringtone sales. Thus, one
line music sales exceeded CD sales nology to them). Mobile phone sales company offered free ringtones as an
in value. According to The Korea grew six times between 2004 and advertisement or enticement for
Times, South Koreans spent 400 bil- 2005, and the first half of 2006 saw their other services, and paid noth-
lion won buying music from tradi- sales of 39.2 billion won—more ing for using the music.
tional stores in 1999; by 2005, that than 2005’s entire revenue of 33.7
number was down to 108 billion billion won.2 In South Korea, it’s not Music and
won whereas online music pur- just iPods but phones that let you in- commerce in Korea
chases had reached 262 billion won.1 stantly choose and listen to new As an example of the current business
The exchange rate is roughly 1,000 music while walking around. The environment for South Korean mu-
won to every US dollar, so convert- leading vendors are telecommunica- sicians, the singer Rain announced a
ing the word “billion” to “million” tions companies, not computer world tour in 2006 with a plan to
gives US readers an idea of what’s manufacturers; and much of the take in 106 billion won. The tour’s
going on in a country one-sixth the market is subscription-based rather organizers, Star M, wrote on the
US’s size and with 1/15th of its gross than item-by-item downloads. singer’s Web site (www.bi-rain.org)
domestic product. South Korea’s most successful that “about 56 billion won will come
A typical South Korean mobile unlimited subscription service is from admission fees, 20 billion from
phone is a camera as well as a music MelOn—owned by SK Telecom, the tour’s copyrights, eight billion
player, and some include video play- the country’s largest telecom com- from DVD sales, six billion from

PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY 85
 Digital Protection
Table 1. Impact of free downloads.
INCREASE (%) DECREASE (%)
CD and 21 5 royalties from digital downloads.
merchandise sales
Concert attendance 30 0 for each iTunes sale of an Allman
merchandise, five billion from mo-
bile revenues, five billion from Inter-
net revenues, 4.5 billion won from
the singer’s photo album, and 1.3 bil-
lion won from broadcasting copy-
rights.” Note that the royalties on the
familiar plastic disks are roughly 20
percent of the revenue—they’re not
the lion’s share of the gross.
US rock groups also get more
revenue from concert tickets than
from recordings. Marie Connolly
and Alan Krueger point out that,
“For the top 35 artists as a whole, in-
come from touring exceeded in-
come from record sales by a ratio of
7.5 to 1 in 2002.”3 According to the
International Federation of the
Phonographic Industry, US record
sales in 2004 were roughly $12 bil-
lion, whereas concert ticket sales
were roughly $2 billion. Why? The
split of concert revenue is quite dif-
ferent: once past initial expenses and
the guaranty, a band might get 85
percent of the remaining revenue
and the promoter 15 percent.3 The
band usually gets all the T-shirt
money; the concert promoter gets
the beer sales. Recording sales are
handled differently. The band might
be entitled to a royalty of 10 percent
of the wholesale price after subtract-
ing payment to the band’s producer
and paying recording and promotion
costs. The musicians might wind up
with at most a small percent of what
consumers pay, but they often end up
with nothing—thus, from their
viewpoint, CDs are just concert ad-
vertising. Their goal is to make the
concerts a “hot ticket” so that they
can charge very high prices for them.
So do musicians do better with
music sold via online download ser-
vices? Not really. Royalties are paid
86 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
to the same recording companies
and are relatively small. In 2006, the
Allman Brothers and Cheap Trick
sued Sony BMG for a larger share of
According to The Wall Street Journal,
Brothers song at 99 cents, Sony gets
80 cents, and the Allman Brothers
get 4.5 cents.4 Adding insult to in-
jury, Sony then charges the musi-
cians for packaging costs and
breakage during shipping, tradi-
tional deductions from royalties that
wouldn’t seem to apply to iTunes.
The bands’ lawsuit is primarily
about the distinction between sales
and licenses, something familiar to
those few who care about the paper-
work that comes with software.
Sony accounts to the band for
iTunes purchases as if they were sales,
but insists to music purchasers that
they’re only buying licenses. If Sony
were forced to be consistent, the All-
man Brothers would get more
money (perhaps up to 80 times
more) or consumers would acquire
more rights than Sony wants them
to have (the right to transfer or resell
the songs, for example).
Table 1 shows the results from a
2004 survey5 in which researchers
interviewed musicians and asked
them whether free downloads in-
creased or decreased their sales of
recordings or concert tickets. Those
who didn’t answer “increase” or
“decrease” said “no effect,” “don’t
know,” or “not applicable.”
Musicians, in general, aren’t the
leaders in the copyright–piracy de-
bate. Recording companies might
be suffering as CD sales drop, but
the musicians get so little from
record sales that the losses have less
impact on them. It’s remarkable
how small the bands’ share of the
money is, considering the market
power you might think they have.
Smaller groups do even worse.
Where’s the variety?
In terms of online download ser-
vices’ effect on creativity, the real
question is deeper and more confus-
ing. In the varied music world,
which is more welcoming to new
artists: the CD market, the down-
load market, or the concert market?
In recent years, both CD and con-
cert music sales have become more
concentrated as users buy fewer dif-
ferent items than in the past, with the
biggest names getting more of the
money.5 In contrast, the variety of
online music is growing, following
the phenomenon known as “The
Long Tail.”6 iTunes carries roughly 4
million songs; no conventional
record store has more than, say,
150,000. However, the concentra-
tion of conventional sales is greater
than this comparison would suggest.
Stores like Tower Records (60,000
titles per store) have gone out of
business whereas Wal-Mart, with
5,000 titles per store, now represents
one-fifth of the CD business.7 Simi-
larly, concert revenues are increas-
ingly concentrated, although this
partly reflects greater pricing accu-
racy, as the most popular bands
charge higher prices to capture the
revenue previously lost to scalpers.
This logic would suggest that if all
the traditional revenue sources went
away and consumers bought all of
their music online, we’d probably
have a greater variety of music avail-
able than we do now. Musicians
would still get relatively little, but
they’d have an easier time starting out
from scratch than they do now (you
could argue that the chances for new
bands could hardly get any worse).
Locked no more
Another consumer-friendly step
forward in South Korea comes by
legal force. The MelOn service uses
DRM technology to restrict their
players to its own downloads (just in
case you wondered why this article
belongs in this department). Re-
cently, the South Korean Fair Trade
Commission (KFTC)—responsible
for antitrust law enforcement—
fined SK Telecom 330 million won,
saying that as the dominant com-

pany in the mobile MP3 phone
market, it must let people play other
legal MP3 songs on its handsets.2
What this means is that SK Telecom
can still have its music store, but it
will have to let other music stores sell
tracks that play on its phones. Of
course, the KFTC’s ruling allows ac-
cess to those individuals ready to
give away MP3s, whether of their
own music, poetry readings, or just
their dog barking. In the South Ko-
rean context, this makes some sense:
the government built the telecom
backbone network, so all providers
should have an equal chance to op-
erate over the SK Telecom music
service infrastructure.
The US is also moving in this di-
rection; even the big music compa-
nies are starting to make material
available in unlocked formats.9 Many
smaller vendors already sell unlocked
music—it’s their best way to deliver
material that will play on an Apple
iPod. If we all move toward MP3 as a
general music format instead of
DRM-encoded material, we should
again expect an increase in the vari-
ety of music and of the gadgets to
play it. As an example, South Kore-
ans are considering clothing with
built-in music hardware.7 (You could
always start by combining head-
phones and earmuffs.)
Strangely enough, the fastest
growing part of the digital download
business is classical music, which is
otherwise a backwater of the music
industry. Although the music indus-
try generally moans that digital rev-
enues aren’t yet compensating for
declining CD sales, classical music
revenues in the US (online and CD
sales combined) were actually up
22.5 percent in 2006, according to
Nielsen Music’s 2006 Year-End
Music Industry Report (http://biz.
yahoo.com/bw/070104/20070104
005813.html). Classical music is 3 to
4 percent of music sales in stores, but
it’s 12 percent of iTunes sales.10 Clas-
sical listeners are generally older and
thought to be less likely to illegally
download music; thus, it makes
Digital Protection
sense that this demographic would alties,” The Wall Street Journal, 28
be the first place that a new legal Apr. 2006.
marketing system for online music 5. M. Peitz and P. Waelbroeck, “An
would pay off. Economists’s Guide to Digital
Music,” working paper no. 1333,
Munich Soc. for the Promotion of
S o what’s in store for the future—
that as seen in South Korea or in
classical music? Either way, I’m fairly 6.
Economic Research (CESifo
GmbH), 2004.
C. Anderson, The Long Tail, Hype-
optimistic: it looks as if we’re moving rion, 2006.
to a world of relatively available and 7. W. Cohen, “Wal-Mart Wants $10
affordable online and mobile music CDs,” Rolling Stone, 12 Oct. 2004.
with fewer restrictions than we have 8. A. Veiga, “Music to Be Offered in
now. Keep your fingers crossed. MP3 File Format,” The Associated
Press, 6 Dec. 2006.
References 9. The Associated Press, “South
1. C. Garcia, “K-Pop Struggles to Korea Wants People in ‘Smart’
Boost Sales,” The Korea Times, 30 Clothes,” 16 Aug. 2006.
Jan. 2007. 10. C. Higgins, “Big Demand for
2. Yonhap News, “Corporate Watch- Classical Downloads is Music to
dog Fines SK Telecom for Incom- Ears of Record Industry,” The
patible MP3 Service,” 20 Dec. Guardian, 28 Mar. 2006.
2006; http://english.yna.co.kr/
Engnews/20061220/6600000000 Michael Lesk is a professor and chair of
20061220135710E8.html. the library and information science
department at Rutgers University. His
3. M. Connolly and A.B. Krueger,
research interests include digital libraries,
“Rockonomics: The Economics of computer networks, and databases. Lesk
Popular Music,” working paper no. has a PhD in chemical physics from Har-
11282, Nat’l Bureau of Economic vard University. He is a member of the
National Academy of Engineering, the
Research (NBER), 2005.
ACM, the IEEE, and the American Society
4. E. Smith, “Sony BMG Is Sued by for Information Science and Technology
Bands Over Song-Download Roy- (ASIS&T). Contact him at lesk@acm.org.
Call for Papers
October–December 2007 issue on:
Security & Privacy in Pervasive Computing
Submission Deadline: 1 May 2007
IEEE Pervasive Computing invites submissions to a special issue on Security and Privacy
in Pervasive Computing. Example topics include, but are not limited to, the following:
• Establishing trust in pervasive hardware • Using tamper-evident hardware
• Preserving security in cyber foraging • Providing peripheral awareness
• Software and hardware attestation of trust context
of remote executions • Combining privacy with accuracy
• Authenticating with low distraction in location sensing
AUTHOR GUIDELINES: www.computer.org/pervasive/author.htm
PUBLICATION DATE: September 2007
GUEST EDITORS
M. Satyanarayanan, Carnegie Mellon University
George Cybenko, Dartmouth College
Jason Hong, Carnegie Mellon University
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 87
 Building Security In
Editors: John Steven, jsteven@cigital.com
Gunnar Peterson, gunnar@arctecgroup.net

A Metrics Framework
to Drive Application
Security Improvement

W
eb applications’ functionality and user base over time, and help establish baselines
for anomaly detection. When com-
have evolved along with the threat landscape. bined with runtime metrics, deploy-
ment-time metrics give insight into
Although controls such as network firewalls the rate of change and key service-
level agreement metrics such as avail-
are essential, they’re wholly insufficient for ability, mean time between failures,
and mean time to repair.
providing overall Web application security. They provide security Runtime metrics focus on the
Web application’s behavior in pro-
E LIZABETH A. for underlying hosts and a means of If you develop, manage, or ad- duction and the security vulnerabili-
N ICHOLS communication, but do little to aid minister Web application software ties discovered after deployment.
ClearPoint the application resist attack against and want to measure, analyze, and Vulnerability discovery at runtime
Metrics its software implementation or de- improve a development culture that causes the most expense both in
sign. Enterprises must therefore produces secure code, this article terms of application performance
G UNNAR focus on the security of the Web ap- provides an excellent starting point. and customer impact. Over time, if
PETERSON plication itself. But in doing so, the metrics collected in the earlier
Arctec Group questions immediately arise: “What Life-cycle metrics phases show improvement due to
could go wrong with my software? Software development managers design and deployment process
How vulnerable are my existing ap- use design-time metrics to make changes, then we would expect to
plications to the most common risk-management decisions when see a corresponding improvement in
problems? What changes to my soft- defining, implementing, and build- runtime metrics.
ware development life cycle might ing software and related security The notion of design-time,
affect these vulnerabilities?” mechanisms. Both managers and deployment-time, and runtime
The Open Web Application Se- developers should harvest design- metrics are particularly illustrative
curity Project (OWASP; www.owa time metrics from source code via because they apply to distinct phases
sp.org) Top Ten offers a starting static analysis, from audits and assess- of the software development life
point for figuring out what could go ments, and iteratively from other cycle. We can harvest runtime met-
wrong. This installment of Build- runtime and deployment-time met- rics, for example, in the quality as-
ing Security In presents metrics that rics. The importance of design-time surance phase.
can help quantify the impact that metrics stems from their ability to
process changes in one life-cycle identify and characterize weak- Top Ten items
phase have on other phases. For the nesses early in the application’s life To explore some explicit metrics,
purposes of this short discussion, cycle, when such weaknesses cost let’s review each OWASP Top Ten
we’ve broken an application’s life much less to fix.1 item and an example design, deploy-
cycle into three main phases: design, Deployment-time metrics mea- ment, or runtime metric for it.
deployment, and runtime. By orga- sure changes to the system and its
nizing metrics according to life configuration over time. A common Unvalidated input
cycle in addition to OWASP type, (if oversimplified) view is that change The first item—unvalidated input—
insight from the derived quantita- is the enemy of security. Deploy- involves the information from Web
tive results can potentially point to ment-time metrics provide hard data requests that isn’t validated before
defective processes and even suggest to characterize the amount of change the Web application uses it. Attack-
strategies for improvement. actually present, uncover patterns ers can exploit these weaknesses to

88 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY

compromise back-end components
through the Web application.
A good design-time metric is
“PercentValidatedInput.” To com-
pute this metric, let T equal the
count of the amount of input forms
or interfaces the application exposes
(the number of HTML form
POSTs, GETs, and so on) and let V
equal the number of these interfaces
that use input validation mecha-
nisms. The ratio V/T makes a strong
statement about the Web applica-
tion’s vulnerability to exploits from
invalid input—the higher the per-
centage, the better. If a company sees
that all of its Web applications have
low values for PercentValidatedIn-
put, then mandating the use of a
standard input validation framework
would drive lasting improvement for
current and future applications.
Broken access control
The second item—broken access
control—means the application fails
to impose and enforce proper re-
strictions on what authenticated
users may do. Attackers can exploit
such weaknesses to access other
users’ accounts, view sensitive files,
or use unauthorized functions.
An example runtime metric is
AnomalousSessionCount, which we
compute in two phases. The first
phase derives a SessionTableAccess-
Profile by correlating application
server user log entries for a user ses-
sion with accessed database tables;
the resulting value of SessionTable-
AccessProfile is represented as a user
ID followed by a set of ordered pairs
with a table name and a count. The
second phase derives the Anom-
alousSessionCount by counting
how many SessionTableAccess-
Counts don’t fit a predefined user
profile. If AnamalousSessionCount
is greater than one for any user, espe-
cially a privileged user, it could indi-
cate the need for significant
refactoring and redesign of the Web
application’s persistence layer. This is
a clear case in which detection at de-
sign time is preferable.
Broken authentication
and session management
The third item—broken authentica-
tion and session management—
means the application doesn’t
properly protect account credentials
and session tokens. Attackers that
compromise passwords, keys, session
cookies, or other tokens can defeat
authentication restrictions and as-
sume other users’ identities.
An example runtime metric is
BrokenAccountCount, which we
can compute by counting the num-
ber of accounts that have no activity
for more than 90 days and will never
expire. Such accounts represent a
clear risk of password compromise
and resulting illegal access.
Cross-site scripting
With the fourth item—cross-site
scripting or XSS—attackers can use
the Web application as a mechanism
to transport an attack to a user’s
browser. A successful attack can dis-
close the user’s session token, attack
the local machine, or spoof content
to fool the user.
An example runtime metric is
XsiteVulnCount, which we can ob-
tain via a penetration-testing tool.
The results will likely enter a bug-
tracking process (developers can
quickly fix XSS bugs). However, this
is another case in which catching the
problem earlier is far better than later.
Buffer overflow
The fifth item—buffer over-
flows—can crash Web application
components such as libraries and
drivers in languages that fail to vali-
Organizing metrics by OWASP Top Ten
category and software life-cycle phase
can drive improvement in existing processes.
date input, or, in some cases, at-
tackers can use them to take
control of a process.
An example deployment time
www.computer.org/security/
Building Security In
metric is OverflowVulnCount,
which we can obtain from standard
vulnerability management tools that
identify the patch level of installed
software against the patch levels that
repair known buffer overflow flaws.
Another useful set of metrics pro-
vide statistics around the patching
latency for known overflow vulner-
abilities. To compute these metrics,
calculate the minimum, maximum,
mean, and standard deviation of the
number of minutes/hours/days it
took to patch detected overflow vul-
nerabilities during a given time pe-
riod. A high mean or a high standard
deviation indicates either slow or in-
consistent patching processes.
Injection flaws
The sixth item—injection flaws—
involves the Web application as it
passes parameters when accessing
external systems or the local operat-
ing system. If an attacker embeds
malicious commands in these para-
meters, the external system can exe-
cute those commands on the Web
application’s behalf.
An example runtime metric is
InjectionFlawCount, which we
can derive from penetration tests
that submit invalid parameters to a
running copy of the Web applica-
tion. This metric characterizes the
Web application’s vulnerability to
potential attacks. Another runtime
metric is ExploitedFlawCount,
which we can derive from reported
incidents in which an attacker suc-
cessfully exploited the application
via an injection flaw. This metric
characterizes the impact actually
suffered. Both metrics offer excel-
lent feedback to the development
organization about inadequate pa-
rameter checking.
■ IEEE SECURITY & PRIVACY 89
 Building Security In
Figure 1. Security scorecard. This layout helps reviewers assess one or more of the Web
application’s current states and quality by providing a color-coded score for each
category of Open Web Application Security Project (OWASP; www.owasp.org) flaw.
Improper error handling
With the seventh item—improper
error handling—the application
source code doesn’t properly check or
handle error conditions that occur
during normal operation. If an at-
tacker can introduce errors that the
Web application doesn’t handle, he or
she can gain detailed system informa-
tion, deny service, cause security
mechanisms to fail, or crash the server.
For a design-time metric, use a
static analysis tool to count the
number of function calls that don’t
check return values. This “instance
per application” count provides a
good indicator of improper error
handling’s prevalence. A simple raw
count performs best. In this case, di-
viding by the number of all function
calls to normalize a raw count into a
percentage potentially masks a seri-
ous problem.
Insecure storage
The eighth item—insecure storage—
illustrates how Web applications fre-
quently use cryptographic functions
to protect information and credentials.
90 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
However, these functions and the
code needed to integrate them have
proven difficult to code properly, fre-
quently resulting in weak protection.
For a deployment-time metric,
compute the percentage of servers
with installed and active automatic
hard-disk encryption to find the level
of protection available as part of a Web
application’s operating environment.
In short, the higher the metric value,
the higher level of protection.
Application denial
of service
With the ninth item—denial of ser-
vice—attackers can consume Web
application resources to a point
where other, legitimate users can no
longer access or use the application.
Attackers can also lock users out of
their accounts or even cause the en-
tire application to fail.
For a runtime metric, derive
metrics from penetration tests that
cover denial-of-service attacks. Vul-
nerability discovery can help here,
but preventing denial of service can
be a complicated design issue.
Insecure configuration
management
The final item—insecure configura-
tion management—focuses on how
secure Web applications depend on a
strong server configuration. Servers
possess many configuration options
that affect security, and no default
configuration is secure.
For a deployment-time metric,
count the number of service ac-
counts (the ones a program uses to
log into services such as database
management systems) with weak or
default passwords. This indicator
helps quantify the risk of illegal ac-
cess, breach of confidentiality, and
loss of integrity. Consistent unac-
ceptable exposure warrants better
deployment standards.
A security scorecard
The scorecard in Figure 1 summa-
rizes the relatively fine-grained met-
rics that calculate data values from
penetration testing, static code
analysis, incident management sys-
tems, vulnerability scanners, and
other instrumentation as mentioned
in the previous section. Several of
our client companies have used this
scorecard to track improvement in
security centric coding practices
with their respective Web applica-
tion development organizations.
The scorecard gives a calculated
rating for seven of the OWASP Top
Ten categories. Color helps translate
the metric results to a more qualita-
tive state: red for bad, green for
good, and yellow for somewhere in
between. If you perform this exer-
cise in your own company, the keys
to success include forming consen-
sus around the mapping and only
making changes in a controlled and
fully auditable manner. Making a
change based on a pseudo-political
need to turn a red into a yellow or a
yellow into a green will cause a lot of
damage in the long run, rendering
the scorecard and its underlying
metrics useless.
The following steps, inspired by
the Six Sigma framework (www.isix

sigma.com), help map quantitative
metric data into color-coded ratings:
• Express each underlying metric in
terms of defects divided by oppor-
tunities. If, for example, a Web ap-
plication has 100 input forms, and
12 of them have defective input
validation, then the application
gets a rating of 88. The equation is
1.0 – (#defects/#opportunities).
• Map values to colors by compar-
ing each value to thresholds. For
example, your group could estab-
lish that red maps to values less
than 80, yellow maps to values be-
tween 81 to 90, and green maps to
values over 91.
• Aggregate all individual Web ap-
plication scores in a given vulnera-
bility category to create a single
“summary” score.
On this last point, you can do the
mapping of many scores to one
color-coded state in several different
ways. Some possibilities are:
• The assigned state for the entire
vulnerability category takes the
worst value or color. This harsh
but useful method gives lagging
applications a lot of visibility and
stresses improvement for the cate-
gory’s worst score.
• Map the mean of all individual
metrics to a color via a threshold
mechanism.
• Compute a weighted mean of all
individual metrics on the appli-
cation’s agreed upon criticality
(consensus is key here). Map the
weighted mean to a state using a
threshold mechanism.
• Map the mean minus the standard
deviation of all individual metrics
to a state for a particular category.
This approach favors consistency.
• Map the value of the lowest appli-
cation in the top decile (or quartile
and so on) to a state.
The scorecard provides additional in-
dicators that show an upward, down-
ward, or unmoving trend for the
Building Security In
given time period relative to previous
periods. Subordinate scorecards can
include trend lines covering several
historical time periods.
T o enrich the above quantitative
scoring, analysts should also
include qualitative, unstructured Engineering
annotations to the scorecard, de-
scribing how to use the data pro- & Applying
vided, what objectives it serves,
how to interpret the results, and the Internet
what actions the company has ini-
tiated as a result of the insights de-
rived. In this way, organizations can IEEE Internet Computing
begin to organize the myriad fine- reports emerging tools,
grained metrics derived from their technologies, and
existing infrastructure and effi- applications implemented
ciently drive application security through the Internet
improvement. to support a worldwide
As for the time involved, you can computing environment.
implement and regularly review a
scorecard such as the one in Figure 1
incrementally by starting with easily
In 2007, we’ll look at:
obtained metrics such as those from
your currently existing penetration • Autonomic Computing
testers, static code scanners, and in- • Roaming
cident management systems. In our • Distance Learning
own tests, in which we used a pur- • Dynamic Information
pose-built security metrics plat- Dissemination
form, the scorecard took roughly • Knowledge Management
two weeks of effort from initial de- • Social Search
sign to deployment for automatic
metric production.
For submission information
References and author guidelines,
1. D.E. Geer, A.R. Jaquith, and K. Soo please visit
Hoo, “Information Security: Why www.computer.org/
the Future Belongs to the Quants,” internet/author.htm
IEEE Security & Privacy, vol. 1, no.
4, 2003, pp. 24–32.
Elizabeth A. Nichols is the Chief Technol-
ogy Officer at ClearPoint Metrics. Her re-
search interests include information security
metrics design, automation, visualization,
and benchmarking. Nichols has a PhD in
mathematics from Duke University. Con-
tact her at ean@clearpointmetrics.com.
Gunnar Peterson is a founder and man-
aging principal at Arctec Group, which
supports clients in strategic technology
decision making and architecture. His work
focuses on distributed systems security
architecture, design, process, and delivery.
Contact him at gunnar@arctecgroup.net. www.computer.org/internet/
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 91
 Emerging Standards
Editors: Rick Kuhn, kuhn@nist.gov
Susan Landau, susan.landau@sun.com
Ramaswamy Chandramouli, mouli@nist.gov

Infrastructure Standards for

Smart ID Card Deployment

S
mart card deployment is increasing thanks to the A core component of the infra-
structure for supporting identity-
addition of security features and improvements in based applications, in general—and
smart ID cards, in particular—thus
computing power to support cryptographic algo- consists of product offerings with
varying functionality and interfaces.
rithms with bigger footprints (for digitally signing Our search to identify areas for stan-
dardization in the smart ID card sys-
and encrypting) in the smart card chips in the past five or six years. tem infrastructure therefore starts
with information flows in and out of
RAMASWAMY Typical applications include sub- Smart ID card the IDMS. Based on a conceptual
CHANDRAMOULI scriber identification module (SIM) system infrastructure understanding of IDMS as the
US National cards (in telecommunications), mi- At the heart of the smart ID card sys- repository of all credentials, it’s easy
Institute of cropayments (in financial transac- tem infrastructure is the identity man- to see that it should have two kinds
Standards & tions), commuter cards (in urban agement system (IDMS), which of information flow streams:
Technology transportation systems), and identifi- includes both a data repository and a
cation (ID) cards. Although the software system that many organiza- • The credential-collection stream (CCS)
PHILIP LEE share of cards used for identification tions use to support identity-based consists of all information flows
Identity applications (which we’ll call smart applications such as single sign-on needed to gather and consolidate
Alliance ID cards) is relatively small within and authorization management. credentials from multiple sources.
the overall smart card market, it’s one Broadly, the two most common areas Different types of credentials or
of the fastest growing segments. of identity-based applications are credential-related information ori-
Smart ID cards control physical physical access-control systems (PACS) ginate from these sources and flow
access to secure facilities and logical and logical access-control systems into the IDMS.
access to IT systems (Web servers, (LACS). Despite the IDMS’s versa- • The credential-provisioning stream
database servers, and workstations) tility, no agreed-upon definition ex- (CPS) consists of all information
and applications. Authentication of ists for its functional scope. Its flows to various end points (or tar-
the card and holder takes place using a canonical function as the manager of get systems) that need to perform
set of credentials. An organization de- all forms of enterprise-wide cre- identity verification. Where iden-
ploying such cards must have an infra- dentials (identity information) is re- tity verification takes place, au-
structure for generating, collecting, cognized, but individual product thentication credentials (a subset
storing, provisioning, and maintain- offerings vary widely in their func- of the credentials stored in IDMS)
ing credentials. The components in- tionality. The points of variation in- flow from IDMS to the access-
volved in these credential life-cycle clude the types of corporate (meta) control entities, such as door pan-
management activities constitute directories to which the IDMS can els or IT application systems.
what we’ll call the smart ID card system interface (LDAP, for example),
infrastructure, which supports smart ID native database management sys- When the authenticating credentials
card deployment. tem support (relational or object- used for identity verification are
Not all components involved in oriented), the data schemas’ long pieces of data (say, 25 bytes
this infrastructure have standardized expressive power (some IDMSs sup- rather than 4-digit personal identifi-
interfaces. Moreover, no robust port the capture of authorization in- cation numbers) or the authentica-
messaging standards exist for infor- formation such as roles, groups, and tion process involves sophisticated
mation exchange among the com- user IDs), and the mechanisms for transactions (a cryptographic proto-
ponents. Yet, some efforts are under connecting to the systems to which col rather than the exchange of a
way to partially address the standards the IDMS must provision the creden- simple shared secret, for example),
gap in this area. tials (connectors, agents, and so on). credential verification requires a

92 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/07/$25.00 © 2007 IEEE ■ IEEE SECURITY & PRIVACY
 Emerging Standards

smart card. Along with this require- Background

ment, the associated infrastructure
needs a new component, called a
card-management system (CMS), to se-
curely populate the card with the
credentials and to track the card’s sta-
tus regarding whether it’s active, sus-
pended, terminated, lost, or stolen.
Like a PACS or LACS, the CMS be-
comes the target of provisioning in
its own right in a smart ID card sys-
tem infrastructure. Hence informa-
tion flow from the IDMS to CMS
becomes an important component
of the CPS.
To design this infrastructure to
meet an enterprise’s functional and
security needs, the enterprise con-
sumer needs some market choices
for all of the components. Yet, inter-
face standards between the key infra-
structure components are critical for
ensuring that integrating compo-
nents that meet the enterprise needs
isn’t a tedious and technically chal-
lenging task. In the rest of this article,
we identify the components and dis-
cuss whether interface standards
exist for them. Our scope encom-
passes both types of interface specifi-
cations—those for program-level
(APIs) and message-level (messaging
interface) interactions.
Figure 1 illustrates the compo-
nents in a typical smart ID card system
infrastructure, including numbered
information flows for the CCS and
CPS. Credential sources are the compo-
nents from which CCSs originate,
and credential targets are the compo-
nents into which CPSs terminate
(except for CPS-2C).
Information flows
in credential
collection stream
All credentials originate primarily
from the human resources (HR) sys-
tems or their equivalents within a
given organization (personnel man-
agement systems, contractor reg-
istries, and so on). The person to be
issued a smart ID card is called an ap-
plicant until the time the smart ID
Enrollment workstation
CCS-2
CPS-1
Physical access-
control system (PACS)
(server and panels)
Card-management system
Smart card
Graphical CPS-2A
Personalization modules
Electrical CPS-2B
Figure 1. Smart ID card system infrastructure components. Numbered information flows for the
credential-collection stream (marked as CCS-x) and credential-provisioning stream (marked as
CPS-x) illustrate the flow of information into and out of the IDMS component, respectively.
card is physically issued, and a card
holder thereafter. The first CCS
(marked as CCS-1 in Figure 1) is the
pre-enrollment package, which con-
tains the following information:
• applicant demographic informa-
tion (name, address, social-security
number, gender, birth date, and
so on),
• applicant affiliation information
(organization, department or divi-
sion, country of citizenship, and
status in the organization [such as
employee or contractor], and so
on), and
• sponsorship information (seal of
approval attesting that the appli-
cant is eligible to receive a smart
ID card).
Once the pre-enrollment pack-
age is entered, the IDMS or sponsor
notifies the applicant to go through
the enrollment process at an enroll-
ment workstation (EWS; see Figure
1), which collects the applicant’s
biometric information and per-
forms identity proofing or vetting
by examining the breeder documents,
such as birth certificate, passport,
driver’s license, and residency and
work permits.
Enterprise HR system
investigation service
CCS-1 CCS-3
Identity-management
system (IDMS) Credential
database
CPS-3
CPS-2
Single-sign-on directories
(Logical access-
control system [LACS])
CPS-2C
PKI server
Glossary
API: application programming interface
CCS: credential-collection stream
CMS: card-management system
CPS: credential-provisioning stream
EWS: enrollment workstation
IDMS: identity management system
LACS: logical access-control systems
PACS: physical access-control systems
PC/SC: personal computer smart card
PKCS: public-key cryptography standard
PKI: public-key infrastructure
SDK: software development kit
The enrollment package gener-
ated from this process flows from the
EWS to the IDMS (marked as CCS-
2) and consists of the biometric in-
formation (facial image, fingerprint,
and templates) and scanned copies of
the breeder documents. The organi-
zation planning to issue a smart ID
card sends out applicant’s demo-
graphic information along with a
subset of the enrollment package
(particularly the fingerprints) per-
taining to that applicant for back-
ground investigation to verify
whether the applicant is a law-abid-
ing citizen. An example of such a

www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 93

 Emerging Standards
background investigation in the US
is an FBI criminal history check.
The appropriate authority in the or-
ganization then adjudicates the in-
To design the smart ID card infrastructure to
meet an enterprise’s functional and security
needs, the enterprise consumer needs some
market choices for all of the components.
vestigation report and sends the
result to the IDMS (CCS-3).
Interface standards
with credential-
source components
Based on the process flow we’ve de-
scribed, the infrastructure involved
in credential collection consists of
the following credential-source compo-
nents (and interfaces):
• enterprise HR system-to-IDMS
interface
• EWS-to-IDMS interface.
Enterprise HR systems are gener-
ally legacy IT systems (or cus-
tomized HR modules from
enterprise resource planning offer-
ings) with heterogeneous database-
management systems. Although of
recent origin, IDMSs don’t have
standardized APIs or messaging in-
terfaces. In the absence of interface
specifications, HR systems and
IDMSs use custom Web interfaces
(all IDMSs come with Web inter-
faces). System integrators therefore
have to make choices in the follow-
ing areas for standardizing and se-
curing interactions or information
flows between enterprise HR sys-
tems and IDMSs:
• secure network protocols,
• data and messaging syntax, and
• message-level protections.
In the area of secure network
94 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
protocols between Web interfaces,
the standard industry practice is to
specify the use of Secure HTTP (at
the session level) and Transport
Layer Security (at the transport
level). If a Web service interface sup-
porting a service-oriented protocol
is involved, the associated secure ver-
sion of application protocols such as
SOAP 2.0 must also be specified.
The messages in both directions
(HR systems to IDMS and IDMS to
HR systems, for example) must also
be identified. Our reference archi-
tecture for the smart ID card system
infrastructure includes the following
messages related to the CCS:
• pre-enrollment package upload
from HR systems to IDMS (for
transferring CCS-1),
• pre-enrollment package response
from IDMS to HR systems,
• enrollment package upload from
EWS to IDMS (for transferring
CCS-2), and
• adjudication package upload from
HR systems to IDMS (for trans-
ferring CCS-3).
Because of the diverse platforms on
which the components involved in
transferring these messages are
hosted, a machine-independent
transfer syntax is needed. Again, the
state of the practice is to choose
XML, which means expressing the
semantic structure of the messages
through an artifact called XML
schema. An XML schema for a given
message flow (in the context of the
smart ID card infrastructure) es-
sentially consists of the description of
the various credentialing elements.
Given that the set of credentialing el-
ements can vary by organization, it
isn’t possible to define a “standard
XML schema” for any given message
flow in the infrastructure. However,
one school of thought advocates that
a generic XML schema consisting of
all possible credentialing elements
can be defined to include a manda-
tory set and make the rest optional
elements. The argument in favor of
this approach is that it can establish
uniformity in the syntactical repre-
sentation of a given credential type
(expiration date, for example), thus
facilitating support for multiple iden-
tity-based applications using the
same infrastructure.
Continuing with our process-
flow analysis, we find that the enroll-
ment package is the collection stream
flowing from the EWS to the IDMS.
An important aspect to remember is
that an EWS could be an in-house
system or be located at an enrollment
service provider site (and hence
under a different IT administration
domain). Even with an in-house
EWS system, the physical location
could be a remote site and hence re-
quire use of the public network for
communications. Given the nature of
EWS-to-IDMS interactions and the
fact that no programming or mes-
sage-level interface specifications
exist for IDMS, the process needs the
same standardized set of require-
ments specified for HR system-to-
IDMS interactions. Furthermore, the
message-level protections assume
added importance in EWS-to-IDMS
interaction because the enrollment
package contains privacy-sensitive
information (biometrics and breeder
documents). Organizations making
use of either an in-house or service
provider EWS to receive enrollment
packages must therefore ensure that
these packages are delivered through
secure channels and that the neces-
sary hardware and software elements
(cryptographic modules) involved in
providing the channels have the certi-
fication requirements consistent with
cryptographic strength requirements.
One last aspect of the process flow

related to credential collection in the
smart ID card system infrastructure is
the flow of information from IDMS
to background-verification systems.
At least one such system—namely,
the US Visit/IDENT system—pro-
vides a complete message interface
specification requiring:
• secure network protocols and
message-level protection (SOAP
2.0 with client-side secure sockets
layer authentication) and
• data and messaging syntax (XML,
12 message types with XML
schema for each).
Let’s now examine the portion of
the infrastructure involved in cre-
dential provisioning. To do so, we
must identify all information flows
that are part of the CPS, just as we
did with the CCS.
Information flows
in the credential-
provisioning stream
All information flows in the CPS
originate from the IDMS; the infor-
mation content and number of flows
depends on the type of authentica-
tion application. The various infor-
mation flows include:
• physical access-control informa-
tion (cardholder name, facial
image, unique credentialing num-
ber, expiration date, or status) be-
tween IDMS and PACS (marked
as CPS-1 in Figure 1);
• card-resident credential informa-
tion (all credentials that will even-
tually reside on the card) between
the IDMS and CMS (marked as
CPS-2);
• graphical card-personalization in-
formation (all visual information
found on the card such as the pho-
tograph, issuing organization’s seal,
and cardholder name) from the
CMS to card printers (CPS-2A);
• electrical card-personalization in-
formation from the CMS to the
smart ID card (CPS-2B);
• digitally signed third-party attesta-
tion of identity and credentials—
the PKI certificates provided by a
certificate authority—between
the CMS and a PKI Server (CPS-
2C); and
• logical access-control information
(cardholder name, a unique identi-
fier such as user principal name, or-
ganizational role, or clearance level)
between IDMS and an LACS
module such as a single-sign-on
(SSO) directory (CPS-3).
Having identified the information
flows and the participating compo-
nents, our next step is to look at the
nature of the interfaces that these
components present.
Interface standards
with credential-target
components
The credential-target components
(and interfaces) involved in creden-
tial provisioning in the infrastructure
are the:
• IDMS-to-PACS panel interface,
• IDMS-to-corporate directory in-
terfaces (to support logical access
control through single-sign-on
mechanisms),
• IDMS-to-CMS interface, and
• CMS-to-PKI servers.
The information flows from CMS to
the provisioning end points (the
physical smart card, for example) are
also part of the CPS; hence, the cre-
dential-provisioning function in-
cludes the CMS-to-card printer
The interface between IDMS and corporate
directories is one of the few areas where
standardized interfaces are available.
interface and the CMS-to-card inter-
face (through the card reader device).
Like enterprise HR systems,
most PACSs are stand-alone (rarely
www.computer.org/security/
Emerging Standards
connected to enterprise networks)
legacy systems without standardized
APIs or messaging interfaces. The
two primary components are the
PACS server (the main data reposi-
tory containing physical access-con-
trol information) and the PACS
panel, which maintains a cache of the
data required (in the form of a
lookup table) for restricting physical
access; the PACS panel activates a
lock to open doors or turnstiles once
the smart-card reader (called a PACS
reader) matches the submitted data
against the lookup table. Given that
PACSs predate smart card and
IDMS deployments (they were de-
veloped to work with magnetic
stripe cards), the norm for getting
access-control data into PACS
servers (CPS-1) is through cus-
tomized data-downloading scripts
that periodically batch transfer data
from relevant authorized sources
such as HR systems and physical se-
curity office databases.
Because of the huge investment
in PACS systems (even single large
organizations generally have PACS
from different manufacturers), the
US Department of Homeland
Security is sponsoring efforts to
develop a middleware-oriented
approach for interfacing between
IDMSs and multiple PACSs. Under
this approach, organizations can de-
ploy PACS proxies with a standard-
ized messaging interface that
includes the following components:
• secure network protocols (SOAP
over HTTP),
• data and messaging syntax (XML
syntax, two main message types,
and XML schemas for each mes-
sage format), and
• message-level protections that
■ IEEE SECURITY & PRIVACY 95
 Emerging Standards
provide mutual authentication be-
tween the IDMS and PACS.
The interface required between
IDMS and corporate directories for
transferring credential information
for logical access control (CPS-3) is
one of the few areas in which stan-
dardized interfaces are available with
the help of secure directory access
protocols such as LDAP.
The IDMS-to-CMS interface is
perhaps the most important one in
the infrastructure. A CMS maintains
life-cycle data such as card status and
credential status and populates smart
cards with credentials by establishing
secure sessions. Hence all card-
resident information (CPS-2) must
be transferred from IDMS to CMS.
As Figure 1 illustrates, the CMS, in
turn, has to distribute or add to this
information by communicating with
other provisioning end-point enti-
ties such as PKI servers, card print-
ers, and the smart card to be
populated. CMS communicates with
the following entities to perform the
associated functions:
• PKI servers to request and obtain
digital identity certificates to cre-
ate bindings between cards and
credentials;
• cryptographic libraries (not shown
in Figure 1) to generate public–
private key pairs and digitally sign
some credential objects that will
go onto the card;
• card printers to print cardholder
names, photographs, security fea-
tures such as holographic patterns,
and so on; and
• smart cards for electrical personal-
ization of credentials in a card’s
data objects or containers.
The most notable feature with
respect to integrating CMS with
other components in the smart ID
card infrastructure is that almost all
CMS vendors provide their own
proprietary software development
kits (SDKs) consisting of program-
ming interface libraries for upload-
96 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2007
ing information to and extracting
information from the CMS. These
SDK libraries facilitate the task of
transferring card-resident credential
information (CPS-2) from the
IDMS to the CMS, as well as trans-
ferring graphical card-personaliza-
tion information (CPS-2A) from
the CMS to card printers. The
downside is that these SDKs are
useful only for integrating specific,
designated CMS products; organi-
zations must deploy new SDKs and
develop new sets of data transfer
programs if the CMS product in
the smart ID card infrastructure
changes. That said, the following
platform- and product-neutral spec-
ifications are available for integrating
CMS with PKI servers (for transfer-
ring CPS-2C) and smart cards (for
transferring CPS-2B):
• Public-Key Cryptography Stan-
dard (PKCS) #10 is a messaging
specification for requesting digital
certificates from PKI servers run
by different certificate authorities.
• Global Platform Messaging and
API specifications (published by
the Globalplatform.org industry
consortium) enables a CMS to
electrically personalize smart cards
in a secure way.
A fter a smart ID card is issued,
various components perform
the actual authentication functions.
These include the host application
and the service-provider middle-
ware that provides specialized func-
tions, such as financial transactions
and telecommunications, related to
the smart card’s application area. Be-
cause these components technically
form part of the smart card user in-
terface architecture, rather than the
infrastructure architecture, we didn’t
consider their interfaces in this arti-
cle. Even restricting our focus to in-
frastructure components in smart ID
card systems, we find that the process
is still in the early stages of transition-
ing from the use of customized data-
upload and download scripts and
communication sockets to the use of
standardized application and net-
work-layer protocols (that include
security) using partially defined
messaging specifications. Upgrading
this process to one with standardized
procedures can occur only when the
components in the smart ID card
system infrastructure have standard-
ized APIs or message-level interface
specifications. An alternate path to-
ward this goal would be to employ
middleware with standardized APIs
for connecting to each of these com-
ponents. For now, the road for both
approaches seems long. Organiza-
tions deploying smart ID cards will
have to live with proprietary APIs
and messaging specifications for
some time to come.
Ramaswamy Chandramouli is the direc-
tor of the NIST Personal Identity Verifi-
cation Program (NPIVP) at the US
National Institute of Standards & Tech-
nology. His research interests include for-
mal model-based testing, security
architectures, role-based access control,
and Domain Name System security.
Chandramouli has a PhD in Information
Security from George Mason University.
He is coauthor of Role-Based Access
Control (Artech House, 2007), which is
now in its second edition. Contact him at
mouli@nist.gov.
Philip Lee is a partner at Identity Alliance.
His research interests include studying
the convergence of the US government’s
Personal Identify Verification Program
applications and existing enterprise iden-
tity-management solutions, as well as
evaluating the feasibility of specialized
biometric applications such as Match-
On-Card. Lee has an MS in computer sci-
ence from the University of Maryland. He
is a member of the Smart Card Alliance
and ASIS International. Contact him at
lee@identityalliance.com.
Interested in writing for this
department? Please contact editors
Rick Kuhn, kuhn@nist.gov,
Susan Landau, susan.landau@
sun.com, and Ramaswamy
Chandramouli, mouli@nist.gov.
 5

C ELEBRATING
S OUTH K OREA’ S D IGITAL W AVE • I DENTITY M ANAGEMENT S YSTEMS

YEARS

MARCH/APRIL 2007 BUILDING CONFIDENCE IN A NETWORKED WORLD

VOLUME 5, NUMBER 2
IEEE SECURITY & PRIVACY • MALWARE • VOLUME 5 • NUMBER 2 • MARCH/APRIL 2007
MARCH/APRIL 2007
VOLUME 5, NUMBER 2

BUILDING CONFIDENCE IN A NETWORKED WORLD

Features
Malware

15 Guest Editor’s Introduction

IVÁN ARCE

17 Studying Bluetooth Malware

Propagation: The BlueBag Project
LUCA CARETTONI, CLAUDIO MERLONI, AND STEFANO ZANERO

Bluetooth worms currently pose relatively little

danger compared to Internet scanning worms.
The BlueBag project shows targeted attacks
through Bluetooth malware using proof-of-
concept codes and mobile devices. COVER ARTWORK BY GIACOMO MARCHESI, WWW.GIACOMOMARCHESI.COM

26 Alien vs. Quine

VANESSA GRATZER AND DAVID NACCACHE
identification of malware. Entropy analysis
enables analysts to quickly and efficiently
identify packed and encrypted samples.
Is it possible to prove a computer is malware-free
without pulling out its hard disk? The authors
introduce a hardware inspection technique based
46 Code Normalization
for Self-Mutating Malware
on the injection of carefully crafted code and the DANILO BRUSCHI, LORENZO MARTIGNONI, AND MATTIA MONGA
analysis of its output and execution time.
Next-generation malware will adopt self-mutation

32 Toward Automated Dynamic

Malware Analysis Using CWSandbox
to circumvent current detection techniques. The
authors’ strategy reduces different instances of the
CARSTEN WILLEMS, THORSTEN HOLZ , AND FELIX FREILING same malware into a common form that can
enable accurate detection.
The authors present CWSandbox, which
executes malware samples in a simulated Identity Management
environment, monitors all system calls, and
automatically generates a detailed report to
simplify the malware analyst’s task.
55 Trust Negotiation in Identity Management
ABHILASHA BHARGAV-SPANTZEL, ANNA C. SQUICCIARINI,
AND ELISA BERTINO

40 Using Entropy Analysis

to Find Encrypted and Packed Malware
Most organizations require the verification of
personal information before providing services;
ROBERT LYDA AND JAMES HAMROCK the privacy of such information is of growing
In statically analyzing large sample collections, concern. The authors show how federal IdM
packed and encrypted malware pose a systems can better protect users’ information
significant challenge to automating the when integrated with trust negotiation.

Postmaster: Send undelivered copies and address changes to IEEE Security & Privacy, Circulation Dept., PO Box 3014, Los Alamitos, CA 90720-1314. Periodicals postage rate paid at New York, NY, and at additional mailing offices. Canadian
GST #125634188. Canada Post Publications Mail Agreement Number 40013885. Return undeliverable Canadian addresses to PO Box 122, Niagara Falls, ON L2E 6S8. Printed in the USA.
Circulation: IEEE Security & Privacy (ISSN 1540-7993) is published bimonthly by the IEEE Computer Society. IEEE Headquarters, Three Park Ave., 17th Floor, New York, NY 10016-5997; IEEE Computer Society Publications Office, 10662 Los
Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1314, phone +1 714 821 8380; IEEE Computer Society Headquarters, 1730 Massachusetts Ave. NW, Washington, DC 20036-1903. Subscription rates: IEEE Computer Society members
get the lowest rates and choice of media option—$24/29/29 US print + online/sister society/individual nonmember. Go to www.computer.org/subscribe to order and for more information on other subscription prices. Nonmember rate:
available on request. Back issues: $25 for members and $98 for nonmembers.
Copyright and reprint permissions: Abstracting is permitted with credit to the source. Libraries are permitted to photocopy beyond the limits of US copyright law for the private use of patrons 1) those post-1977 articles that carry
a code at the bottom of the first page, provided the per-copy fee indicated in the code is paid through the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923; and 2) pre-1978 articles without fee. For other copying,
reprint, or republication permissions, write to the Copyright and Permissions Department, IEEE Service Center, 445 Hoes Lane, Piscataway, NJ 08855-1331. Copyright © 2007 The Institute of Electrical and Electronics Engineers, Inc. All rights reserved.
 Departments
From the Editors
4 Trusted Computing in Context
FRED B. SCHNEIDER

News
7 News Briefs
BRANDI ORTEGA

Interview
11 Silver Bullet Talks
with Dorothy Denning
GARY MCGRAW

Education SECURE SYSTEMS, P. 80

64 Common Body of Knowledge

Crypto Corner
for Information Security
MARIANTHI THEOHARIDOU AND DIMITRIS GRITZALIS
76 When Cryptographers Turn Lead into Gold
On the Horizon PATRICK P. TSANG

Secure Systems
68 Secure Communication
without Encryption?
KEYE MARTIN
80 A Case (Study) For Usability
in Secure Email Communication
Privacy Interests APU KAPADIA

Digital Protection
72 Setting Boundaries at Borders:
Reconciling Laptop Searches and Privacy
E. MICHAEL POWER, JONATHAN GILHEN,
85 South Korea’s Way to the Future
MICHAEL LESK
AND ROLAND L. TROPE

Building Security In
88 A Metrics Framework to Drive
Application Security Improvement
ELIZABETH A. NICHOLS AND GUNNAR PETERSON

Emerging Standards
92 Infrastructure Standards
for Smart ID Card Deployment
RAMASWAMY CHANDRAMOULI AND PHILIP LEE

84 Ad Product Index

PRIVACY INTERESTS, P. 72 Printed on 100% recycled paper

For more information on these or any other computing topics, please visit the IEEE Computer Society’s Digital Library at http://computer.org/publications/dlib.