Copyright

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.

The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

The publisher offers discounts on this book when ordered in quantity for bulk purchases and special sales. For more information, please contact:

U.S. Corporate and Government Sales

(800) 382-3419

corpsales@pearsontechgroup.com

For sales outside of the U.S. please contact:

International Sales

(317) 581-3793

international@pearsontechgroup.com

Visit Addison-Wesley on the Web: www.awprofessional.com

Library of Congress Cataloging-in-Publication Data

Swaminatha, Tara M.

Wireless security and privacy : best practices and design techniques

Tara M. Swaminatha, Charles R. Elden.

p. cm.

Includes bibliographical references and index.

1. Wireless communication systems—Security measures. 2. Wireless communication systems—Design and construction. 3. Privacy, Right of.

I. Elden, Charles R. II. Title.

TK5103.2 .S93 2003

384.5—dc21 2002071657

Copyright © 2003 by Pearson Education, Inc.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. Published simultaneously in Canada.

For information on obtaining permission for use of material from this work, please submit a written request to:

Pearson Education, Inc.

Rights and Contracts Department

75 Arlington Street, Suite 300

Boston, MA 02116

Fax: (617) 848-7047

Text printed on recycled paper

1 2 3 4 5 6 7 8 9 10—CRS—0605040302

First printing, September, 2002

Dedication

To my grandparents, Joseph and Nora McGraw

—T.M.S.

To my wife, Sandra

—C.R.E.


Foreword

Wireless security is becoming increasingly important as wireless applications and systems are widely adopted. Numerous organizations have already installed or are busy installing Wireless Local Area Networks (WLANs). These networks, based on the IEEE 802.11b standard, are very easy to deploy and inexpensive. Other important trends in wireless adoption include the introduction of wireless e-mail with devices such as the BlackBerry and the Palm VII, rampant digital cell phone use (including the use of Short Message Service [SMS]), and the advent of Bluetooth devices. Wireless is clearly here to stay.

But all is not well in the wireless universe. The risks associated with the adoption of wireless networking are only now coming to light. A number of impressive attacks are possible and have been heavily publicized, especially in the IEEE 802.11b arena. Since October 2000, at least ten major wireless security stories have played out (see Table F.1 ). These stories were covered by the New York Times, the Wall Street Journal, CNN, and NBC Nightly News, among others. Apparently, the world finds wireless security both interesting and important.

Table F.1. A Chronology of Wireless Security Topics, Issues, and Stories (Incomplete)

When

Who

What

Web

October 2000

Jesse Walker of the University of Maryland

Several problems in WEP

http://www.cs.umd.edu/~waa/wireless.html

January 2001

U.C. Berkeley researchers Nikita Borisov, Ian Goldberg, and David Wagner

Seminal work on WEP insecurity

http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html

March 2001

University of Maryland researchers Bill Arbaugh, Narendar Shankar, and Justin Wan

Several access control and authentication problems in 802.11b

http://www.cs.umd.edu/~waa/wireless.pdf

June 2001

Tim Newsham from @stake

A key generation algorithm problem leading to dictionary attacks

http://www.lava.net/~newsham/wlan/

August 2001

Scott Fluhrer, Itsik Mantin, and Adi Shamir

A cryptographic flaw in the RC4 key setup algorithm used by WEP

August 2001

Avi Rubin from AT&T Research and Adam Stubblefield of Rice University

Implementation of the WEP crack

http://www.nytimes.com/2001/08/19/technology/19WIRE.html

October 2001

Bob Fleck from Cigital's Software Security Group

ARP cache poisoning attacks that work against 802.11 networks

http://www.cigital.com/news/wireless-sec.html

February 2002

Arunesh Mishra and Bill Arbaugh from the University of Maryland

Several flaws in 802.1X (still in committee)

http://www.cs.umd.edu/~waa/lx.pdf

May 2002

Avi Rubin of AT&T Research

X10 Wireless camera vulnerabilities

http://www.nytimes.com/2002/04/14/technology/14SPY.html

The most interesting thing about wireless security is the opportunity presented by the very recent adoption of wireless technology. New users of wireless technology have a chance to build things properly and securely as they adopt wireless networks and create applications to run on them. That's not to imply that this will be easy, because it will not be. This book presents an important, and a necessary, introduction to critical issues in wireless security, something that will be extremely useful to those adapting wireless technology. Armed with a solid understanding of reality, readers of this book are unlikely to fall prey to hype.

As far as base technology is concerned, wireless security appears to be following the usual "penetrate and patch" route. This is unfortunate, but perhaps unavoidable. Early wireless security is focused almost exclusively on cryptography and secure trans-mission—with unfortunate results thus far. WEP security, the cryptography built in to 802.11b, for example, is completely broken and offers very little real security. In fact, one might argue that using WEP is worse than using no cryptography at all, because it can lull users into a completely unfounded sense of security. Given that our wired networks are in such bad shape, perhaps the notion of attaining "wired equivalent privacy" is ironically accurate after all!

An over reliance on cryptography springs from a misunderstanding of the fact that cryptography is a tool with which to approach security (and not security itself). This misunderstanding is deeply entrenched in many other subfields of security, especially software security, where "magic crypto fairy dust" is sprinkled liberally over designs in hope of attaining an easy security solution. Alas, software security is not that easily accomplished. Neither is wireless security.

The Gates memo of January 2002 highlights the importance of building secure software to the future of Microsoft. But software security reaches far beyond shrink-wrapped software of the sort that Microsoft produces. Software has worked its way into the very heart of business and government and has become essential in the new millennium. Software applications will clearly play a crucial role in the successful evolution of wireless systems. This is a critical fact that, to their credit, the authors understand and highlight in this book.

Mature software security practices and sound systems security engineering should be used when designing and building wireless systems. Security measures must be implemented throughout the wireless software development lifecycle, or wireless applications risk running afoul of the same security pitfalls that currently afflict wired applications. The difficulty in constructing a secure wireless system lies in the medium's limitations: Devices are smaller, communications speeds are slower, and consumers are more demanding. These limitations force a trade-off between security and functionality. The trick to sound security is to begin early, know your threats (including language-based flaws and pitfalls), design for security, and subject your design to thorough objective risk analyses and testing.

This book will help.

Gary McGraw, Ph.D.
Trento, Italy
May 2002


Preface

When you're on a journey and the end keeps getting farther and farther away, you realize that the real end is the journey.

—Karlfried Graf Durckheim

This book provides wireless and security professionals with a foundation on which to design secure wireless systems. Most security problems are handled reactively rather than proactively; this does not have to be the case for wireless security. In the past decade, advances in software development have outpaced advances in software security. Wireless technology—still in its infancy—affords the opportunity for proactive security that keeps pace with development.

Wireless Security and Privacy is intended for three types of readers:

1. Security experts interested in wireless issues

2. Wireless experts interested in security issues

3. Business professionals and consumers generally interested in wireless security

We focus on the practices and methodology required to establish comprehensive wireless security. Wireless application developers, wireless device users, service providers, and security professionals are among those who will benefit from the information and analysis presented.

The message presented in this book differs greatly from that offered by most other security texts, which are typically dedicated to dissecting attacks and retroactively presenting lessons learned. Their message is, "Security should have been a priority from the beginning." Our message is, "It's not too late."

In the wired Internet world, applications are released at breakneck speed while security measures lag far behind. Security is considered an isolated step, taken only when time permits. Wireless or wired, applications are pieces of software. Wireless developers can apply certain lessons the wired development community has learned about software security. Secure software practices are an important first step toward building secure systems. If security is taken into consideration before wireless applications become widely available, the myriad problems that have occurred with wired applications can be avoided. Provisions for security must be developed throughout the lifecycles of wireless applications and systems.

Software applications, e-business opportunities, revenues, and reputations have suffered because development teams and businesses have not focused sufficiently on security. It is no accident that phrases such as Internet time have become common. The pace at which new technologies are developed is increasing at an exponential rate. Hardware and software capabilities, communications speeds, and pervasiveness within society have changed the face of IT. Developers, architects, and industry analysts could not have predicted with any degree of certainty the extent to which the wired industry would develop.

If wireless trends mirror current software trends, wireless applications and services will likely become as commonplace as desktop Internet applications. While the world waits for wireless devices and infrastructure to develop and deliver the capabilities of desktop hardware and wired networks, security professionals and wireless architects have a unique opportunity to coordinate their efforts and direct trends in the wireless world. Developers have the responsibility to design secure wireless applications. This can be accomplished only if efforts commence immediately. Software security best practices can help guide the development of effective wireless applications.

It is almost impossible to overestimate the amount of time and money that will be saved if wireless security is set forth as a guiding tenet of wireless architecture. Security will become a best practice that cannot be ignored and a critical element of all application development, with or without wires. Confining security to a single module and considering it only after market (or not considering it at all) should be unthinkable. Security is a process. As such, it must begin in the first stages of design and continue throughout the development cycle. Security must also be constantly reevaluated, even after an application's release.

When the wired Internet first emerged, its primary uses were research and development. Applications emerging on the market were intensely popular and mushroomed in scope and number. Application security, unfortunately, did not have an opportunity to keep pace. Wireless Internet on PDAs will not begin in the same fashion. Rather, it will be used in its early stages for delivering service-oriented, timesaving applications. Most existing wireless applications fall into that very category. The most popular versions of applications accessed through desktop browsers will be available in lightweight versions. Research will not be the primary focus, as consumers demand robust, convenient applications on wireless devices.

The message of this book bears repeating: "It's not too late." However, this message has a second part: "The time to start is now."

The wireless industry has been afforded a luxury that was unavailable to the wired industry: precedence turned into foresight. The catch? Consumers now share this same foresight. Consumers are increasingly aware of the risks they assume in using wired and wireless applications. They have been burned in the wired world and will not be cavalier in their use of wireless applications. Wireless developers must be able to sell their products based on the merits of usability, security, privacy, and reliability. Building verifiable security measures into a product will give it a competitive differentiator. Applications that cannot sufficiently prove their security will quickly become obsolete. Today's wireless application developers must understand that security will soon become a consumer mandate.

Investigation into security practices cannot stop at applications, however. Wireless devices, networks, and applications warrant close examination so that problems can be predicted and prevented.

This book is divided into four sections: Establish a Foundation, Know Your System, Protect Your System, and I-ADD (meaning Identify, Analyze, Define, and Design). The first introduces basic security principles, wireless technologies, and their applications. The last three explain the three phases involved in designing a robust security solution.

Part I: Establish a Foundation

Establish a Foundation is as important to security development as it is to life in general. Beginning an endeavor by learning about all its components prevents many headaches down the road. Furthermore, being mindful of security throughout an entire development process is crucial. Several standard—but often ignored—security principles that apply to the wired Internet world hold important implications for the wireless world.

Chapter 1—Wireless Technologies

Chapter 1 introduces the general principles governing wireless issues today. Wireless experts may find that they do not need this review. If you choose to skim or skip this chapter, however, you should read the case studies at the very end because they are referred to throughout the entire text. The chapter presents a high-level overview of wireless issues and technologies, with the intent of familiarizing you with topics essential in understanding the rest of the book.

Chapter 2—Security Principles

Chapter 2 introduces general security practices and common industry concepts. Security experts can skim this if they feel comfortable with its content. These key principles are important for understanding more complex processes introduced later in the text. In this chapter we introduce a method for developing a security analysis process called I-ADD. This process is based on industry practices but standardizes and organizes the approach. I-ADD is fleshed out beginning in Chapter 9, "Identify Targets and Roles."

Part II: Know Your System

Know Your System presents the first essential step in developing appropriate wireless security practices. This section puts its message into action by demonstrating the results of research efforts paramount to investigating system components when developing a secure system. Technologies, devices, and languages are discussed in great detail so that they can be woven into a security framework.

Chapter 3—Technologies

Chapter 3 takes you through the first phase of our process by presenting detailed information on wireless technologies such as 802.11b, Bluetooth, and Wireless Application Protocol (WAP). Each technology falls in a different place on the wireless technology spectrum and has its own security implications. In the initial phases of developing a comprehensive security solution, knowing the ins and outs of all components is extremely helpful. This chapter shows you what type of information is valuable to know about wireless technology. You have to conduct an exhaustive search of all the system's components before determining which affect security.

Chapter 4—Devices

Much in the same fashion as Chapter 3, Chapter 4 delves into physical and logical aspects of wireless devices. PDAs, cell phones, and laptops with wireless network cards are discussed. As part of the Know Your System section, this chapter teaches you the device intricacies that affect security solutions. Specific devices are investigated, and general recommendations are made. Security implementations must investigate the specific devices and client software on the devices that could affect security in any way. This chapter introduces some of these, but pursuant to its goal of teaching a process, not just a static solution, it educates you about the device issues that have to be considered when developing a comprehensive security package.

Chapter 5—Languages

Chapter 5 is more technical than its two predecessors. Project managers using this book to guide a security implementation may want to refer a developer or development team leader to this chapter. The chapter will not make you an expert wireless developer but shows you those components of wireless development languages that affect security implementations. Designating a team member as the language expert is essential in any wireless project. The language expert should know the security implications of the language backwards and forwards. This chapter helps get the language expert on her way. The languages discussed are presented in light of their potential security downfalls. Mitigations are suggested, and implementations are not complete without consulting this chapter.

Part III: Protect Your System

Protect Your System presents the intermediary step in the security process: developing a risk model. This enables a person with knowledge of a system to decide how best to protect it. By outlining the roles associated with a system, its threats, vulnerabilities, and attacks, you can develop a robust plan. The threat model you develop will help integrate security throughout a system's development lifecycle.

Protect Your System discusses technologies or procedures that affect wireless systems. Although these technologies or procedures may not be directly applicable to any particular architecture or system, the information provided indicates the issues and add-ons to be considered in mitigating security risks.

Chapter 6—Cryptography

In many cases, cryptography is confused with total security. If cryptography is not understood properly, it can be assumed to accomplish far too much or far too little. This chapter serves as an introduction to applied cryptography. Its purpose is to inform you of basic cryptographic principles that should be understood in developing a wireless security solution. This chapter is more technical than others but provides an introductory view for the layperson. It is important to be able to use cryptography as a component of a security solution without making the mistake of thinking that simply encrypting wireless network traffic will solve all security problems.

Chapter 7—COTS

When looking for security, we sometimes fall into another trap—commercial off-the-shelf products (COTS). COTS products offer a false sense of security in some cases. They should be used when necessary and can offer a partial security solution, but they should be understood first and used with great care. This chapter investigates some popular, wireless industry COTS products and examines their role in protecting a wireless application or system.

Chapter 8—Privacy

No discussion of security is complete without considering privacy. Although distinct entities, the two are intertwined in many ways. This chapter teaches the wireless and security professional about the privacy policy and legal issues surrounding wireless technology security at the present time. Understanding the policies under which you are developing a security solution is essential. Furthermore, it is good solid business practice to understand the privacy concerns of consumers and be able to accommodate the changing needs of a wireless user population.

Part IV : I-ADD

The concepts governing wireless security issues are neither new nor distinct from those governing wired issues. In both cases, several steps are involved: Threats must be assessed, risk must be determined, vulnerabilities must be analyzed, and a plan for designing accordingly, based on the first three steps, should be developed.

Chapter 9 — Identify Targets and Roles

Using systems set forth in our case studies, as well as generic wireless systems, Chapter 9 conducts an exhaustive search for potential targets. In this "whiteboard" phase of the analysis, you learn how to dissect components to determine what might be compromised. When this list is completed, you proceed to identify the roles or individuals associated with any of the case study systems that may attempt to compromise or take control of the identified targets. This information gives you a starting block from which to launch the rest of your analysis.

Chapter 10 — Analyze Attacks and Vulnerabilities

When targets and roles have been identified, known attacks, vulnerabilities, and theoretical attacks are analyzed. This analysis examines how these threats affect the resources we want to protect. From this analysis, potential mitigation techniques and protection mechanisms are determined.

Chapter 11 — Analyze Mitigations and Protections

Chapter 11 is where the security plan develops. It is also the culmination of our investigation. Mitigations are implemented against risks, and a robust system ensues. Although the most daunting part of the overall picture, developing the security model, falls into place when you understand the framework, the threats against it, and how to protect it. We systematically proceed through the threat model already developed and discuss how to build security in to places where we have found holes.

Chapter 12 — Define and Design

Inevitably, there are difficult trade-offs and decisions you must make. This chapter revisits the case studies, applies a security model to each, and discusses which components of a security system are necessary, based on what needs to be protected in each case. We apply all the concepts taught in the book and come up with solutions for our cases.


The Advantages of Reading This Book

After reading this book, you should have a solid understanding of the technical basics of security and wireless issues. In addition, you should know how to develop reliable security mitigations in wireless systems, based on the results of a process that includes learning a system, assessing its risks, and developing an appropriate security framework. Situations will arise in which security and functionality trade-offs are necessary. Those decision makers armed with a full understanding of the risks involved will have a distinct advantage. Should business requirements dictate that certain vulnerabilities remain unmitigated, appropriate contingency plans can be developed. In the event of a system compromise, business can continue as usual because security was an integral part of the system's development. Uninformed counterparts, however, will likely be busy fighting fires and attempting to force security measures into their existing infrastructures.

For more information on this book or for other books useful in designing and developing systems, please consult the Addison-Wesley Web site at http://www.awprofessional.com .


About the Authors

Tara M. Swaminatha is an Information Security Administrator for the International Finance Corporation, a part of the World Bank Group. Tara is responsible for educating the IFC about information security, conducting technical product evaluations, offering security classes to employees, and assisting with the definition and implementation of plans for security best practices and technologies. Previously, Tara was a software security consultant with Cigital's Software Security Group (SSG). The SSG provides software security risk analysis for a broad range of clients. Tara also worked for PEC Solutions on a team that developed software and infrastructure for agencies within the U.S. Department of Justice. She implemented configuration control practices, maintained integrity of the development and production environments, and performed software, hardware, and multi-system integration. Tara holds both a B.A. in sociology and an M.T. in special education from the University of Virginia, where she graduated with high distinction. While working at the IFC, Tara is also currently pursuing her J.D. at Georgetown University.

Charles R. Elden is an Independent Security Consultant. He worked most recently at Cigital, where he was a manager and software security consultant with Cigital's Software Security Group. He has experience performing communication and software systems risk analysis and risk management. Prior to this, Charles worked for the Central Intelligence Agency for 12 years and has worked for over 11 years in the Directorate of Science and Technology's Office of Technical Services. Charles has extensive experience designing, developing, deploying, and exploiting secure and covert computing and communication systems. Charles received his M.S. in computer science from George Mason University and his B.S. in computer science/computer engineering from Michigan State University.


Acknowledgments

Tara and Charles would like to thank Gary McGraw, Doug Morrison, Scott Nichols, Jared Karro, and Brian O'Beirne for their assistance, feedback, input, revisions, and suggestions.

Special thanks go to Tadayoshi Kohno for his invaluable contribution.

Tara would like to thank her parents, Norine and Kris, and her sisters, Sheela, Meara, and Neala, for their constant support, encouragement, and friendship throughout the writing of this book—as well as throughout her life. She also thanks the following people for constantly supporting, challenging, and laughing with her: JMG, RBG, KBC, RAM, AMM, EFM, GWL, TGT, BMD, SLR, AMH, CDG, MGMF, JSB, JSB, AMS, SRH, and SLN. Special thanks go to Charles for his exceptional and untiring contributions and motivation throughout the past year. Without him, this project would not have been a success.

Charles would like to thank his loving wife, Sandra, for all her patience, support, and understanding during the many long hours and weekends lost to this effort. He also thanks his supportive family and loyal friends for all their encouragement throughout the years. Finally, Charles would like to thank Tara for encouraging him to coauthor this book and for her confidence in him. He is grateful that she shared this opportunity.


Part I: Establish a Foundation

Chapter 1. Wireless Technologies

Chapter 2. Security Principles


Chapter 1. Wireless Technologies

A journey of a thousand miles begins with one step.

—Chinese proverb

Writing a chapter on wireless security is as easy as writing one on computers, the Internet, first aid, or applying to college. Each could be the subject of a dissertation, a semester-long course, or an entire book. To study a technology without learning its security risks and adaptations is to be remiss. The first component of our investigation is wireless architectures. We describe a typical system and examine its parts: devices, technologies, and network arrangements. We then lay out case studies of conceptual wireless systems so that we can discuss in real terms, throughout the book, security issues and best practices for building a secure system. Our secondary goal is to present information about wireless systems and about security principles. Our primary goal is to teach the process of securing a system from the ground up.

You should be able to read this text and come away with

· The experience of walking, step by step, through a top-to-bottom security risk assessment and mitigation plan

· Knowledge of wireless issues that are important to understand to protect wireless systems


An Introduction to Wireless Architecture

The basic components of a wireless architecture remain the same throughout different systems. Each implementation and technology, of course, sees variations and different options, but by way of introduction, they resemble one another. The architecture we use to represent a generic framework depicts wireless devices retrieving information from a server on the wired Internet by way of its own communication across a wireless network (see Figure 1.1 ). Other implementations and purposes for wireless communication are discussed throughout the book.

Figure 1.1. A generic system architecture

The first component on our diagram is the device. Devices in a wireless system can be cell phones, Personal Digital Assistants (PDAs), laptops with wireless network cards, or any device that communicates without wires. These devices operate over wireless networks and communicate with towers called bearers. These bearers have popped up alongside highways across the world. Unlike the telephone or radio towers of old, bearers are not connected by aboveground wires visible from the road. Bearers are in charge of passing information sent wirelessly to a wired network. They receive data and transmit it to a component that forwards it via wires to the wired Internet. This component is sometimes a wireless gateway and other times another specialized server designed to be the pivot point between wireless and wired communication. A gateway performs translations among protocols, sessions, encryption, and all else necessary to prepare wireless data for transmission over the wired Internet to its destination.

In our architecture diagram, we will examine one typical scenario—the wireless device requesting information from a Web page on a Web server. The gateway, in this situation, translates the request into one that is readable by the Internet and sends it to the appropriate server. The server processes the request and returns the information to the gateway via the wired Internet. At this point, the wireless gateway performs the necessary transformations again and transmits the data to a bearer, which, in turn, forwards it to the device. The device renders the information on its display screen, and an iteration of this communication cycle is complete. Wireless technologies are generally the final link between an existing wired network, its resources, and new-generation wireless devices.


Usage Models

The architecture we just described is generic; myriad usage models would fit in to this architecture. The following usage models focus on the first part of the communication cycle, the device to the network or devices to other devices, but the models also serve as important illustrators of the capabilities in wireless devices.

Internet Bridge

The Internet bridge architecture best fits a usage model wherein a wireless network serves as a bridge between the wireless device and the wired Internet. In this model, the mobile device is used to wirelessly connect to a wired system (refer to Figure 1.1 ).

Conference

Users at a conference often want to share information. In a keynote session, for example, a presenter may want to share her slides with the audience members who come up afterwards to pose questions (see Figure 1.2 ). If the audience members and presenter have wireless devices, they can exchange documents and business cards immediately.

Figure 1.2. The conference usage model

Multipurpose Phone

A cell phone is used in place of a landline at home, connected to a fixed line. When its owner is on the go, the phone is used as a mobile device for initiating and receiving calls. When the same phone is close to another, similar phone, they can participate in two-way communication and avoid a phone service charge, provided that they obtain service from the same provider.

Synchronizer

Mobile devices can automatically synchronize among one another to provide an easy way to stay organized. A user's desktop, PDA, wireless-enabled laptop, and cell phone can be synchronized as soon as information is entered into any of them. A laptop can be automatically updated when information is received in a cell phone, just as a PDA can propagate its new business card contact information to the other devices.

Now we will examine in more detail the important components of a wireless architecture: devices and technologies. The security implications of each will be discussed still further throughout the text, as well as how to avoid the risks associated with each component.


Devices

Wireless devices as they exist today will be obsolete by the time wireless communication becomes the status quo. Recall the desktop PCs with hard drives less than 1MB capacity and monitors with black screens and green lettering. This is how antiquated today's devices will seem in the next generations of devices and technology—which presents quite a dilemma. Developers and designers have to make a decision: Code to existing devices to maximize their functionality, or code more generally so that as devices evolve, they will be compatible with legacy code. Unfortunately, the answer is both. In all fairness, it is virtually impossible to predict what the devices of the future will look like, how they will function, and how they will be used. However, developers must bear in mind that applications have to be scalable. Without a doubt, they will need to be scaled in the very near future.

The wired world sees computers and their components and accessories coming down in price rapidly. Their wireless counterparts are in such a state of flux that some pieces are dropping in price while others are temporarily rising. Consumers who buy the most recent devices on the market pay the early-adopter tax of expensive equipment and communications costs, as well as the tax of having devices that will not necessarily become the standard.

Cell Phones and Personal Digital Assistants (PDAs)

It is best to think of wireless devices in terms of the generation to which they belong. First-generation cell phones, for example, were popular in the last five years of the twentieth century (see Figure 1.3). These phones were analog, had poor reception, were typically large and cumbersome, and weighed more than the commonest second-generation phones of the early twenty-first century. Access plans were expensive per minute, coverage was strictly limited, and concepts such as browsing the World Wide Web on your phone were foreign and futuristic.

Figure 1.3. PDAs, cell phones, and wireless laptops

Towards the end of the 1990s, wireless network providers began to forge digital networks across the globe. These networks supported much sleeker devices, from digital phones with configurable ringing tones and primitive Web-browsing capabilities to PDAs in the form of Palm Pilots, BlackBerries, Pocket PCs, or Visors. These PDAs serve as combination organizers and limited computers. They afford early adopters the ability to browse the Web, albeit slowly, synchronize information between a PC and a PDA, and send text messages or e-mails via wireless networks. Hybrid devices are also available, combination mobile phones and PDAs such as the Microsoft Smart Phone 2002 and the Handspring Treo.

Several debates have ensued since the advancement of cellular phones and PDAs into a third generation of devices. Which will become the treasured device? Cell phones are decreasing in size but need larger display screens. PDAs are being produced with larger display screens but are not getting smaller. Will one become obsolete? Will they be interconnected with short-range wireless technologies so that the cell phone calls an ISP for a PDA to connect to the Internet? These answers may be known even by the time this text is published.

Third-generation devices, often referred to as 3G, are still in conceptual phases. While the world waits for better network operations and faster communication speeds, devices are being developed and tested. The initial wave of 3G devices is gaining market share.

Wireless Laptops

Another wireless device that bears mentioning is a wireless-enabled laptop (refer to Figure 1.3). Laptops are certainly heavier and much more cumbersome than phones or PDAs, but they perform with significantly higher capabilities and potential. They can serve as both connected and nonconnected devices, depending on where they are in relationship to a wireless network. Wireless LAN (WLAN) access via a laptop or desktop is becoming an attractive alternative to the cluttered, cable-ridden offices that are the norm. Each of these technologies will need to be compatible with wireless systems, which introduces the first security problem into the mix.

The numerous devices, software available on devices, networks, service providers, vendors, device manufacturers, implementations, and technologies expected to interoperate in the wireless world present a serious risk. For all systems to be compatible with one another, holes will inevitably be left open. Several characteristic features of wireless devices will continue to evolve.

Consumer Issues

When examining device characteristics, there are consumer issues and technical issues. Some consumer issues cross over into technical ones, and vice versa. For the sake of discussion, though, it is easiest to distinguish consumer issues as those usability and external functionality issues associated with a wireless device. Technical issues are those issues concerning operation of the device, the hardware it comprises, and the software that runs on it. Consumer issues are important to consider in making purchasing decisions for consumers and businesses alike.

Display Screen and Input Devices

The most obvious characteristic, frequently given only cursory attention, is the size of the display screen on a wireless device. Anyone who has attempted to run an application or use functionality on a device can attest that the screen size is a limiting factor if it is not large enough. Factors that are not always considered but have implications for development are

· Resolution

· Colors

· Behavior under certain conditions, such as heat (left on a car dash in the summer) or cold (left in a trunk during the winter)

· Backlighting

· Contrast

· Behavior with different amounts of light

Another related issue is how a user operates the device. Some devices work with numeric keypads, some with touch screens and a stylus, some with detachable keyboards. All these seemingly insignificant factors contribute to a device's functionality and should be considered when choosing devices for specific scenarios.

Peripherals and Expansion

Peripherals and expansion are important consumer issues to consider. If a device has the capability of having components attached to it, it provides extra functionality but also potential vulnerabilities. Peripherals, for example, can turn cell phones into PDAs or give PDAs modem capabilities. By extension, cell phones could become scanners, credit card readers, or cameras, given the right equipment. Not all devices have this capability, and depending on system and user needs, the ability to add external interfaces or functionality may be adding value or creating danger. Some technologies, such as Bluetooth, a short-range wireless technology, open the possibility for devices to become peripherals of one another, enabling users to customize on-the-fly configurations to suit their needs on a changing basis.

Transport

A definite consumer issue is that of transportability. Can I fit the device in my hand? my pocket? or my briefcase? Each option comes with its own constraints and benefits. If a device can be held in one hand, it can be transported easily. It can also, however, be easily stolen, lost, or perhaps broken. Devices that fit in a briefcase are less likely to be lost or misplaced and offer greater potential for processing and storing information. These devices are more attractive to a user who is more concerned with performance than portability. Features inherent to each device make its users more or less able to perform desired tasks. If a user does not save time and energy with a device, she will discard it quickly in favor of one that is either more portable or more capable.

Battery Life

The single biggest limiting factor in wireless devices is physics—the battery. If the Energizer bunny were wireless, devices with wireless capabilities would take on a new life of their own. As for the "It keeps going and going" part, batteries in wireless devices do nothing of the sort. Unbeknownst to the novice user, the types of applications performed on a device directly affect its battery life. A cell phone in use takes far more battery power than a cell phone lying idle. A PDA can outlast a cell phone in terms of power and lifetime, but its applications have to be developed with careful consideration to battery usage. Security capabilities can be significant drains on battery power and can be discarded as wasteful in favor of faster processing without functions like robust encryption. (See Chapter 6, "Cryptography," for a more detailed discussion.)

Communication

Some wireless devices include a property known as peer-to-peer capability. This capability enables device users to form fast, easy connections with each other and to "beam" information to each other. The peer-to-peer feature makes use of an infrared (IR) port on a device, allowing users, in effect, to create their own personal networks. IR communication requires that users be within a short distance of each other but offers significant, attractive possibilities. One limitation of this type of communication is that systems built to make use of IR are often closed systems. Palm and Microsoft systems are closed and therefore cannot talk to each other. Most of their applications use the same standards for transport but not for application exchange. This prevents communication across platforms. If one user has a Palm Pilot, she can likely talk to other Palm users but not necessarily to someone with a Pocket PC. If each device ran an application that enabled the two to exchange information, it would be possible, but the operating systems themselves could not interact. This technology has not been fully developed and may not come to fruition before other forms of wireless networking do. The idea is popular, however, and should be considered when developing wireless applications.

Technical Issues

All operating systems (OSs), development tools, applications, and browsers present complex issues to be investigated. Until one device or operating system manufacturer begins to assert itself as an authority or leader, all of them will be limited in their capability to operate seamlessly with others. Palm Pilots operate with Palm OS, RIM BlackBerry devices operate with their own proprietary operating system, and Pocket PCs operate with the Microsoft platform Windows CE. Some vendors produce devices and license these operating systems for their own use, but these are not highly configurable and are best used as they are delivered. Each device has its own niche in the current market. Palm is easy to use, RIM allows wireless e-mail access, and CE is highly compatible with Microsoft products.

Software Development Kits (SDKs) are another important factor to investigate when examining a device. If application designers find more comprehensive SDKs for one device than for another, they may choose to streamline their development process and gear applications to the device with the better SDK.

When considering all the ramifications of analyzing a device, it is important to note the three major players involved: the hardware manufacturer for the device, the operating system or software vendor, and the wireless network service provider. The hardware manufacturer has extensive control over what can go on the device. In most cases, this company provides a limited set of options from which service providers can choose. Often, too, a partnership exists between the operating system vendor and hardware manufacturer (or the two may be from the same company). The joint OS and hardware production efforts present options to service providers, who choose limited customization options.

The browser, for instance, on a mobile device such as a cell phone or PDA is preconfigured when it is purchased, and the ability to update it is still evolving. Surely, in the near future, this will be a must in devices. The ability to tweak the software installed on a device is a necessity for properly protecting oneself from discovered security vulnerabilities. Just as in the wired world, there will be patches and updates, and there will need to be easy ways for them to be applied by average users. Currently, some devices allow this capability with hardware that can be connected to a PC, but the demand for faster, wireless methods of doing so is increasing.

In the cell phone realm, for instance, one wireless service provider's phones come with a software application that provides a type of list to the device, including identification information about those bearers with which the phone can communicate. As new bearers are installed, the software must be updated for the phone to be able to communicate with the new towers. Currently, this function can be performed only at a retail store or an authorized reseller. Updating this software is a cumbersome and undesirable process. If the software could be updated transparently each time a person initiated a call, say, on the first of each month, the device would be more attractive. Also, the device would incur a new set of security risks.

The service provider often dictates which features will be available on a device in order for it to agree to provide service for device owners. This can be something simple, such as the preset bookmarks in a browser, or something more complex, such as limiting the gateways the device can access to the provider's own.

The involvement by each of these entities in configuring devices is often at the expense of a user's ability to customize a device or protect herself against compromise. In most cases, this cannot be prevented, but it is important to remember when assessing the risks involved in a certain system.


Network Arrangements and Technologies

Wireless technology has been around since the days before radios became popular. The astronauts in a space shuttle communicate to mission control without wires, just as a cordless phone allows people anywhere on the globe to communicate without the burden of wires tying them to a fixed location. Wireless technologies as defined in this text, however, are newer and more sophisticated, operating at higher speeds and conforming to different standards. In this text we introduce three types of wireless technologies:

· 802.11b

· The Wireless Application Protocol (WAP)

· Bluetooth

Some wireless technologies are standards-based wireless transport protocols, some are application protocols, and some are both, but all are technologies. They represent a broad range of technologies, and continually evolving ones at that. It is essential to realize that the only appropriate way to secure a system is to investigate it thoroughly. This book does so with the technologies presented, but its goal is to teach the method for doing so, not to provide answers that will be pervasive in their details throughout the next thirty years. The methods taught here for analyzing a system are invaluable and are tailored specifically to wireless systems. They should be further customized as standards, protocols, and technologies change in the future. Each technology is discussed in much greater detail in Chapter 3, "Technologies."

To place the technologies in appropriate contexts, we will simultaneously examine different network arrangements typically used in wireless systems:

· Personal area networks (PANs)

· Local area networks (LANs)

· Wide area networks (WANs)

The technologies discussed here cross all three network arrangements, but some are more closely associated with one. The discussion of wireless LANs comprises the bulk of this section because it is the most commonly seen implementation of a wireless network for most home and office environments. In the discussion of PANs, it is best to focus on Bluetooth technology. In the discussions of WANs and LANs, it is best to discuss a combination of 802.11b and WAP. These technologies cover different layers of the architecture of each type of network.

802.11b

The most comprehensive technology examined here, 802.11b is a standard developed by the Institute for Electronics and Electrical Engineers (IEEE). 802.11b is the IEEE standard for wireless communications in its revised form, which includes higher communication rates. At the time of the writing of this book, industry analysts indicate that it may be the technology that outlasts the rest and prospers long into the future. (Our opinion is that this may well be true, but parts of the other technologies examined may likely be incorporated into whichever one surfaces as the front-runner for the long term. Furthermore, 802.11b will need to be accompanied by a strict security design paradigm to constitute a viable "total" solution.)

802.11b is backwards compatible with its predecessor, 802.11, and lays out a standard for wireless communication that offers technical specifications about architecture and services, as well as design implementation guidelines. The specifications define components and network configurations and describe the relevant layers of the International Standard Organization's (ISO) Open System Interconnect (OSI) reference model, as well as security implications. Although it may be touted as the most versatile and robust wireless standard that is emerging, 802.11 has been found to have significant problems.

Two reports released in the early part of 2001 unveiled some holes in 802.11 networks. The reports, from the University of California, Berkeley, and the University of Maryland, examined the components of the 802.11 system that attempt to mirror a wired system in terms of security. The examinations led to discoveries of distinct problems and, intentionally or unintentionally, were followed by a steady stream of articles pointing to other insecure measures in the system. Two hundred dollars worth of equipment from Radio Shack was all it took two wily individuals to compromise countless wireless networks in the San Francisco Bay area. These discoveries do not necessarily point to the demise of the technology but rather the need for application security on top of easily implemented networks to bolster weak security measures that come out of the package with these systems.

The Wireless Application Protocol (WAP)

WAP operates at a higher level than transmission protocols such as 802.11b. It provides a protocol used to implement communications in an architecture that requires a gateway to provide the translations between wireless and wired communication. WAP has faced much criticism since its emergence but is currently the leader in cell phone wireless configurations in the United States. WAP browsers, WAP-enabled phones, and WAP development are en vogue, especially in Europe.

WAP includes specifications for application environments, transmission, and session handling, as well as security functionality. In its transport layer, WAP includes a wireless version of Secure Socket Layer (SSL) called Wireless Transport Layer Security (WTLS). WTLS helps secure communication from wireless devices through bearers to WAP gateways (see Figure 1.4). The problem starts at this point. The gateway is a place where the secure communication is vulnerable because the gateway has to translate to communication configured to the standards of the wired Internet. WAP receives its biggest criticism from this. It does not provide end-to-end security and opens holes. WAP specifications use a special language for development of Web pages readable by small devices that communicate on high-latency, low-speed networks.

Figure 1.4. WAP architecture

Wireless Wide Area Networks

Both 802.11b and WAP are used in varying network arrangements. (For the purposes of this text, when referring to a network as wide area network, we mean wireless wide area network. When referring to a WAN connected via wires, we call it a wired WAN. The exception to this is that we employ the acronym WLAN for wireless LANs because this size network is discussed more frequently throughout the book and we want to be clear.) WANs are typically used in the cases of service providers, not corporate or home networks. Loosely, WANs enable devices to connect via wireless technologies and protocols to the Internet, an intranet, or an e-mail system. Depending on the connecting entity, WANs are administered by Internet service providers (ISPs), application providers, or corporations.

WANs are expanding to provide wireless coverage for more areas of the world. Most major cities enjoy WAN service, but rural and less developed areas have not yet seen the benefits of WAN. Remote or underdeveloped areas without wired WANs can benefit from the resources that Internet access brings to an area: infrastructure, communication, necessary supplies, and aid. Also, these great improvements can be realized without the need for costly infrastructure (that is, fiber optic cable) being laid over great distances. Certainly, some cost is involved in implementing a WAN solution to areas with limited resources, but the cost is less than that of wired WAN solutions.

Local Area Networks

A wireless local area network (WLAN) is an electronic data communications system providing an extension, or alternative, to a wired LAN. WLANs use a variety of communication mechanisms to replace the traditional cables and wires of a LAN. In a traditional LAN, data is transmitted as electronic pulses or signals along a physical wire or carrier. Some systems have a continuous signal or carrier running on the wire, such as a tone on the phone line, and the data is superimposed or modulated onto the carrier signal. In a simplified example of the phone, the transmitter makes slight variations to the tone frequency, and the receiver is then set to detect these variations and retrieve the transmitted data. Similarly, in a WLAN, there are transmitters, receivers, and a carrier on which data is modulated.

Currently, two general mechanisms are being employed as the data carrier in WLANs: radio frequency (RF) and infrared (IR). Both mechanisms allow for the trans-mittal and reception of electronic data through the air, minimizing the need for cable and wire connectivity between devices. Several RF technologies are being utilized, and two IR technologies for WLANs. The technologies are Narrowband Technology, Spread Spectrum Technology, Frequency-Hopping Spread Spectrum Technology, Direct-Sequence Spread Spectrum Technology, Direct Infrared Technology, and Diffuse Infrared Technology.

Personal Area Networks and Bluetooth

PANs are networks that focus around an individual. Loosely, a PAN could comprise a cell phone in someone's shirt pocket, his PDA, and his wireless-enabled laptop (see Figure 1.5). The three devices would communicate among one another, forming an ad hoc PAN. The cell phone could dial in to his ISP, offering Internet connectivity to both the PDA and the laptop. The laptop could then send a *.pdf document to the PDA, and the cell phone could disconnect. Each component of the PAN serves a unique purpose, requiring that the three function together to form an intelligent network, but by distributing tasks and functionality, not requiring one heavy cumbersome device.

Figure 1.5. A personal area network (PAN)

The technology that might make this possible is Bluetooth. Bluetooth is a once highly acclaimed technology that has suffered great setbacks. The intention of its major contributors was to develop a standard so that wireless devices could interoperate easily and cheaply in a short-range distance. Adding Bluetooth to a device was supposed to add about five dollars to its cost. Estimates have been off, though, and it is actually costing manufacturers closer to thirty dollars to build the technology into their devices. Perhaps bad luck, perhaps a fortuitous omen, at a conference in April 2001, Bluetooth supporters intended to set a record and have the largest number of Bluetooth users connected at the same time. Not only did they fail to reach their record numbers, but also, because of a system failure, none were able to connect.

Despite setbacks and more than a 30-month delay in mass deployment, Bluetooth slowly gains ground, and developers have yet to abandon it. Bluetooth differs from 802.11b in several ways:

· It can only connect devices within 10 meters of each other.

· It operates similarly to InfraRed Data Assocation (IrDA).

· Its goal is for devices to form networks among each other quickly and easily.

The security ramifications of this are phenomenal. Security is not built in to devices as far as connection capability is concerned. It is left to application developers and, perhaps even scarier, users.

Wireless LAN Appeal

Now that we have introduced a few technologies and network arrangements, there is a question begging to be answered: Why use a wireless LAN? Four main factors describe the appeal of a wireless LAN: mobility, flexibility, cost, and scalability.

Mobility

WLANs can provide users with access to public and private network resources from anywhere within the coverage area. The coverage area may vary quite a bit, depending on the system being used. Some large commercial wireless access providers provide Internet access to large coverage areas. The BellSouth Network and Mobitex cover entire metropolitan areas in most of the United States. We concentrate here on corporate and on home or private wireless networks.

Flexibility

WLANs allow connectivity where running additional cables or wires may be unfeasible or cost-prohibitive. WLANs also allow the configuration or location of the terminals to be tied no longer to the network access; users can rearrange office areas at will and remain connected to the network. Home owners or renters benefit from this flexibility by not having to run network lines throughout a house or an apartment. Yet, they still have access to centralized printers or high-speed Internet access points such as Inte-grated Service Digital Network (ISDN) or a cable modem. These devices can remain wherever they have been installed, and the user's computer can be moved anywhere in the house and still retain access.

Cost

Although the initial cost of WLAN equipment is currently higher than conventional LAN equipment, the cost in installations that are fluid, or temporary and frequently changing, is soon recuperated in rewiring and time.

Scalability

WLAN technologies can be configured in varying topologies to meet the needs of the specific application or installation. These topology configurations are easily changed; new devices or users can be added without affecting existing users or devices. This is truer for some technologies than others, but in general, WLAN technologies are more readily scalable than their LAN counterparts.


Case Studies

Throughout this section, we focus mainly on WLANs. We present several case studies that shape our discussions about security throughout the book. For the sake of clarity, it is helpful to revisit these case studies as you read the book.

Corporate WLANs may or may not provide access to the public Internet and usually have a range of 150–300 feet from the access points. In a corporate environment this is more than adequate in most situations. It allows employees to access the network from anywhere in a building or complex, including courtyards, lunch areas, and the like. The following case studies of this technology describe examples of where this mobility can be of benefit. We have identified four case studies where WLANs are used in place of a wired network: a hospital, an office complex, and a university campus for corporate or business application, and a personal or home WLAN. These case studies serve as the foundation for examining the security aspects of wireless systems in later chapters.

The Hospital

A hospital complex has installed a WLAN system. This hospital complex includes the hospital itself, external buildings housing doctors' offices, and buildings associated with external support facilities. Doctors see patients either in their own office or in the hospital and have complete access to the patients' records on a handheld PDA.

On a typical visit, a doctor, Anne, brings up a chart for her patient, Reggie, and sees that he is in for a follow-up because of an injury to his knee during a weekend bicycle mishap. Anne pulls up the radiologist's report from the preceding visit. The report indicates that the proximal end of the femur sustained a chip at the knee during the accident and that the cartilage is slightly separated from the connective tissue. The radiologist recommended surgery to repair the damage before it becomes worse. Anne approves and seconds the recommendation.

Reggie accesses his own PDA to query his schedule and receive information on his condition from the doctor's system. Anne's PDA system automatically queries her office to update any changes to her schedule, and she cross-references the schedule with that of the anesthesiologist and the hospital's surgery room. Within a matter of seconds, an acceptable date is identified and the surgery is scheduled. The doctor's office system contacts the insurance company and notifies the appropriate case manager of the surgery, and all relevant parties are notified of the event via e-mail while the doctor and patient are discussing the procedure. In the interim, Anne prescribes pain and anti-inflammatory medication for the patient. The prescription is filled out on her PDA and sent to her office computer. Reggie's preferred pharmacist is already in the system, so the prescription is sent to the pharmacy and will be waiting for him when he arrives.

Reggie leaves the examining room and walks to the receptionist's desk, where his record is brought up. The receptionist asks whether he would like the co-pay automatically charged to the credit card on file, to which Reggie responds yes. This is captured by the microphone on the counter and processed by the speech recognition system. The credit card is charged, and the insurance company is sent an electronic bill. Reggie picks up a receipt from the receptionist and is on his way.

Anne now travels to the hospital to make her rounds. She visits a patient, Chris, who is recovering from a car accident. She recommends a change to Chris's medication, inputting the change in her PDA. In turn, the PDA queries the hospital system and returns a potential harmful interaction between the suggested medication and something provided by the emergency room physician. The PDA displays alternatives, Anne selects one, and the change is indicated on Chris's chart and displayed on Anne's PDA while being transmitted to the hospital. Finally, the change is sent to Anne's office system, updating Chris's records.

The nurse who administers the medication carries a notebook, or PDA, on the medication cart. Even though she has already started her rounds, the change is reflected on her screen as she brings up Chris's chart, where the change is highlighted. The nurse smiles to herself (glad that she no longer has to read the doctors' illegible handwriting) and greets Chris warmly as she enters his room.

The Office Complex

An advertising corporation, AdEx Inc., has installed a wireless LAN system throughout its multistory building in Reston, Virginia. It has installed access points at key locations to provide complete coverage throughout the building. Employees are provided laptop computers with docking stations at their work areas. Both the docking stations and the laptops are equipped with wireless LAN access devices. The conference rooms are equipped with projection systems connected to the LAN so that employees can take their laptop to a conference room, connect to the projection system over the network, and control the presentation via their laptop.

An AdEx sales team, headed by Kathleen, is proposing a new marketing campaign to a potential new client, NitroSoft. The team has been working on the presentation for several weeks. Before the presentation, Kathleen takes the NitroSoft group to lunch. During lunch, the NitroSoft people receive a message on their PDAs announcing a new acquisition that has relevance to the team's presentation. One of the people in the NitroSoft group, Louis, mentions the announcement to Kathleen, who takes out her PDA and asks him to send her a copy of the announcement. Louis sends the copy, along with additional background, to her PDA. Kathleen forwards the information to one of her staff members, with instructions on how to incorporate the new information into the presentation.

After lunch, Kathleen and the NitroSoft group return to AdEx and head to the conference room for the presentation. On the way, Kathleen checks her PDA and receives word that her team will be able to incorporate the new information but that it will take 20 more minutes. They inform her that the changes fit well in the second half of the slides. Kathleen tells them that she will begin with the original presentation and then switch to the new presentation halfway through, if they complete it and are satisfied with the results. Otherwise, she will stick with the original presentation.

Kathleen and the NitroSoft group arrive at the conference room and settle in for the presentation. The AdEx sales team continues working as Kathleen begins the presentation. She monitors her PDA and receives confirmation that the team has incorporated the new information and is satisfied with the result. At a convenient point in the presentation, Kathleen loads the updated slides and continues. The NitroSoft group is impressed by the efficiency and speed with which the team was able to incorporate new information. AdEx and NitroSoft close the deal that day.

The University Campus

A university has implemented a campuswide wireless network through which students and faculty can conduct university business. Having prepared his lecture in his office, a professor, Steve, grabs his laptop and heads to the classroom. On arriving at the classroom, he places his laptop on the podium and accesses the lecture hall's projector over the network so that his notes are projected onto the screen at the front of the classroom.

Students have the option of turning in assignments traditionally (on paper) or electronically (which Steve prefers). Assignments are due at the start of class, and Steve has his graduate student teaching assistants (TAs), Brian and Jessie, look over the assignments during the class. Near the end of the lecture, Steve checks his e-mail and receives feedback from the TAs on which parts of the assignment gave the most problems or warrant discussion. Steve expands on these aspects while the assignment is still fresh in the students' minds. As class comes to a close, Steve posts the next assignment, that day's lecture notes, and an answer sheet for the preceding assignment to the class Web page. Students who have a wireless device or laptop can check the page immediately and ask Steve any questions they have, or they can access it at their leisure and e-mail the TAs or him for assistance, if necessary.

One night a week, Brian and Jessie hold a campuswide NetMeeting, where they discuss previous assignments and answer students' questions. Brian and Jessie each have a NetMeeting-enabled wireless laptop, so they can participate and respond to students' questions, regardless of where they are, enabling them to be more productive with their time.

The Home

A home or private WLAN using 802.11b technology has the same range as corporate WLANs, so home users can access their network from anywhere in their house, yard, or, in most cases, their own neighborhood. Home or private WLANs using HomeRF technology have a coverage area up to approximately 150 feet. For this example, it does not matter which system is used because the general capabilities are the same.

Imagine a family in a single-family house in a Chicago suburb. The father, Doug, is a financial advisor for a local credit union. The mother, Emily, holds a part-time job doing online research for a local law firm and volunteers at the local day care. They have two children, an 11-year-old son, Joe, and a 14-year-old daughter, Rachel. They own three desktop computers, and Doug has a laptop, which he uses at home for work. They have a laser printer for printing reports and newsletters for the day care center, a photo-quality ink jet printer, and a cable modem, obtained through a special offer with the local cable service.

The printers and cable modem are connected to the parents' desktop, located in the den/office. A wireless access point is also connected to this computer so that the children's computers and Doug's laptop can make use of the printers and high-speed Internet access. Joe and Rachel each have a desktop in their rooms for doing homework and research on the Web for school. Joe's best friend, who lives across the street, has a wireless adapter in his desktop, so he can connect into the network to utilize the high-speed Internet access for school research, as well as play the occasional network game with Joe. Doug is the only one who can make use of true mobility with his laptop and access the network while lounging in bed, on the couch, or on the back deck. However, the entire family benefits from their computers' capability to utilize the same printers and the cable modem without the need for running cables throughout the house.

With these case studies in mind, let us next investigate the security concepts necessary for building a robust security solution throughout the development of a wireless system. Chapter 2 , "Security Principles," presents industry-accepted and widely adopted security concepts and practices. These practices help shape our discussion and investigation into the specific security issues associated with wireless systems, devices, and applications.


Chapter 2. Security Principles

The early bird gets the worm, but it's the second mouse that gets the cheese.

—Steven Wright

Security is not the result of properly designed and developed software or systems. Rather, it is part of the process used throughout the entire software lifecycle, from design to development, testing, deployment, and obsolescence. Security should be considered before any design is contemplated and long before any code is written or circuits are wired. Too often, security is an afterthought. Developers go straight for the code or the bench because that is where their efforts can first be recognized and because that is considered the "cool stuff."

In this code first, think about it later mentality, the first step is to try to implement the core functionality. Now, we are not saying that following a rapid prototype methodology is wrong, quite the contrary. Performing up-front development to ensure that the technically challenging portions of the development are feasible has merit. However, in a rapid prototyping approach, after the prototype is completed, the final design is developed from scratch, and often the previous development work is discarded, either in whole or to a great extent. The practice we discourage is development in which developers begin expanding and retrofitting to add other features, such as multiplatform support, copy protection, or user interfaces, after functionality is in place. At this stage, some developers even think about scalability or security, although, unfortunately, this does not come until much later in too many cases. Using this latter approach, it is no wonder that software and electronic devices end up with many security vulnerabilities and that more time and money are spent on testing and patching than on the initial design and development.

The good news is, this does not have to be the case. In this text, we give developers, consumers, and managers the information necessary to understand and evaluate the security risks and vulnerabilities of any system, be it consumer applications, wireless devices, or wired networks. At the heart of all these systems—and, we daresay, almost any device these days—is the software. Rarely does an hour go by when we do not rely on some piece of software, either in an application or imbedded in firmware in a clock, coffeepot, streetlight, car ignition system, or home heating system. The list is endless.

With this great reliance on software, you would think that the process of developing and testing the software that goes into these products would be well-defined and refined. The truth is, software development practices stray far from this ideal. The consumer demand for more functionality at a lower cost is giving developers the false notion that they should not take the time to design the software properly, in favor of express coding and producing to meet delivery deadlines.

This logic is seriously flawed. By taking the time (however much or minimal it need be) to follow basic guidelines, developers can be assured that their products will work properly, safely, reliably, securely, faster, and cheaper than if they had begun the development process first. The ability to identify, evaluate, and mitigate the risks (security or otherwise) in a given system requires expert knowledge of both security and the system being evaluated. General knowledge enables you to ask intelligent questions to evaluate at least the high-level risks and, more importantly, to know when a situation requires the advice of a security expert.

We are not going to talk in depth about software security here. However, you should understand that software is the piece of any system that makes the whole puzzle either complete or incomplete. Also, software is usually the component that makes the system susceptible to security vulnerabilities and is the means, if not the cause, of exploiting hardware vulnerabilities. It will suffice to say that software is the most critical component of any system, and this criticality deserves appropriate consideration. Consumers are beginning to demand that software work as advertised, every time, anytime. The Addison-Wesley book Building Secure Software by John Viega and Gary McGraw covers this topic in detail. We recommend the book highly to anyone in the business of developing, using, or purchasing software that must work and must work as intended.


Security Principles

Six principles are commonly used to describe the phases for evaluating a system's security or vulnerability. These principles are Authentication, Access Control and Authorization, Nonrepudiation, Privacy and Confidentiality, Integrity, and Auditing. They are presented here in no particular order and are heavily interdependent. In fact, the relative importance of each depends on the system or component being evaluated.

Authentication

Authentication is the principle that users, processes, or hardware components be able to identify other users, processes, or hardware components in the system as who or what they say they are, and vice versa.

When a wireless device requests service from a local wireless service provider, it presents the system with user credentials. This varies from device to device, but a cellular phone, for example, sends the device's ECN (Electronic Control Number) and DCN (Digital Control Number). The local service provider uses these credentials to authenticate the device as an authorized user of the system. Usually, the DCN is a telephone number, but it can be thought of as a userid. The ECN is linked to the device and is a digital serial number, similar to a password. The ECN is used with the intention of confirming that the device claiming to be an individual's phone with that individual's userid is, in fact, the phone assigned to that individual. Changing a cellular phone's DCN is relatively easy and, in many cases, can be done via the device's keypad. Changing the ECN is a much more difficult task, often requiring proprietary hardware and software. Therefore, a service provider who verifies that both are correct has some assurance that the individual is who she claims to be, that authentication has been established.

Why should anyone care about authentication? Better yet, why should anyone sacrifice functionality for accurate authentication? If a user is using a PDA to transfer funds between a bank account and an investment account with a broker, the user wants to be sure that the bank knows that it is not someone else falsely claiming to be that user and transferring funds to his own bank account. Users want the bank to authenticate that the correct user is making the request.

Access Control and Authorization

Access Control and Authorization is the principle that a process or hardware component be capable of controlling access to whatever resources that process or hardware component represents or controls.

Access Control and Authorization are closely tied to Authentication. This service provides access control by requiring a user to provide authentication to verify that he is authorized to use the service. Access control and authorization can also be seen on the wireless device itself. Many phones have a lockout feature; the user must provide an access code before the device can be used. This feature provides protection against an unauthorized person's accessing a cell phone and assuming the owner's identity when using the cellular service.

Bringing this idea home, picture a wireless network setup in your home. You track your finances by using an accounting program on your desktop computer. You also trade stocks with an online brokerage service and store other personal data on the machine. You do not want anyone to access your wireless network without your permission, so you implement access control to authenticate anyone attempting to access your network.

Nonrepudiation

Nonrepudiation is the principle that a user or process be identifiable and accountable for its actions in a manner that prohibits the user or process from denying its involvement at a later date.

To explain nonrepudiation, we will describe a familiar transaction, charging something to a credit card. A vendor requests a credit card, swipes the card in a reader, and enters the transaction amount. The card reader then contacts the card provider and verifies that the card is valid and the amount requested is acceptable for that person's credit profile. Finally, an authorization message is returned. The reader prints the transaction on a carbonized receipt that provides multiple copies of the transaction. The receipt is presented to the user for her signature. The vendor verifies that the signature matches the one on the card. Both the cardholder and the vendor retain a copy of the receipt. The dual receipts, with the card provider's authorization and signature, provide nonrepudiation. The cardholder cannot deny that she made the transaction, because the vendor has a copy of the receipt with her signature. The vendor cannot modify the transaction (for example, alter the amount), because the cardholder has a copy of the receipt. The nonrepudiation in this example easily transfers to a requirement for wireless m-commerce applications. How to implement such a requirement, however, is not as obvious.

Privacy and Confidentiality

Privacy and Confidentiality is the principle that a user, process, or hardware component have the entitlement to protect its information from unauthorized disclosure.

Lately, this topic has generated a lot of press associated with the protection of credit card information over the Web, legal authorities' subpoenaing e-mail and online purchase records, and the monitoring of ISPs to determine users' surfing habits. It has become clear that consumers, and not just government agencies, are concerned about privacy and confidentiality on wired and wireless networks.

Privacy and confidentiality are a tricky and often contentious issue. Consumers who want to surf the Web in anonymity (or with increased privacy) need to be able to conduct commerce over the Internet, where nonrepudiation for a transaction is necessary. At the same time, a transaction must be confidential.

Certain government agencies would prefer that all communications and transactions be visible, at least, to their specific agency. To make this a reality, several foreign governments have gone so far as to outlaw the use of cryptography. To counter this, privacy fanatics have circumvented even this extreme measure by utilizing steganography instead of cryptography. Steganography is the use of techniques to hide information within other, innocuous-looking data files or streams. Several worldwide conferences on steganography are becoming very well attended. Although steganography provides excellent privacy and confidentiality (after all, it is hard to read what you cannot find), it usually requires a relatively large amount of innocuous data to hide a relatively small amount of payload. Therefore, although intriguing, this technique is not well suited for commercial wireless use, so we will not explore this aspect of confidentiality directly. Rather, we will point out that this idea lends itself to other security uses, such as digital watermarking.

Integrity

Integrity is the principle that a user, process, or hardware component have the capability to verify the accuracy of what is sent or delivered and that the process or hardware component has not been altered in some way.

Integrity has always been of prime importance for consumers conducting transactions electronically. For the most part, it is taken for granted. Today, for example, taxpayers can complete their taxes on the Web and submit them electronically. How many complete a parallel copy of the taxes manually, or at least offline, to ensure that the computations are correct and the proper information is being recorded on the proper forms? Certainly not a majority. Couple this with the thought that these returns are then processed on 25-year-old IRS computer systems, and the lack of integrity should make you shudder. Consumers demand that the processes and services they use provide reliability because they deal with critical information that can have serious consequences if its integrity is not maintained.

Auditing

Auditing is the principle that the activities of a user, process, or hardware component be reviewed to ensure that whatever was performed was appropriate for the given entity.

Auditing can be both a reactive and proactive process—reactive in that audit logs may be examined at a later date as a forensic measure to identify the source of a security problem or to determine the extent of the exposure, proactive in that audit logs may be examined at or near real time to detect abnormal behavior or prevent someone from attempting to bypass security measures. Clearly, the latter is preferable, but examining logs or monitoring user activity in real time is resource-intensive. If this type of monitoring is deemed appropriate, what is monitored must be carefully planned.

Return for a moment to the cell phone ECN/DCN discussion referring to authentication. If service providers truly believed that their ECN/DCN combination for authentication of the end user could not be replicated, they would not perform as much auditing as they do. Service providers routinely implement an automated auditing system to monitor user access for anomalies—for example, the same ECN/DCN combination accessing the system at the same time and the same ECN/DCN pair accessing the network from different locations (say, New York and Miami) within a short time. This activity may be perfectly legitimate, but it falls outside the normal usage pattern and would be flagged in an audit log to be reviewed by one of the service provider's security or auditing staff.

If security could be analyzed and implemented in a vacuum, without other considerations, applying this criteria is all that would be necessary to implement a secure system in any situation. However, in practical applications, security is only one aspect of a complete system. To evaluate the effect that implementing security has on a system, the development or operational principles and the management principles associated with the system must also be considered. We will now briefly discuss these principles to ensure your understanding of the trade-offs made during an analysis of a system and the subsequent implementation of a system, with the proper balance between these principles and security.


Development and Operation Principles

Seven principles commonly describe the phases for evaluating a system during design, under development, or in operation. These principles are Functionality, Utility, Usability, Efficiency, Maintainability, Scalability, and Testability. These, too, are in no particular order, may vary in relevance, and are heavily interdependent.

To illustrate this interdependence, we use a common Project Management trigon that shows the software development trade-off (see Figure 2.1). The attributes of a project may be represented by a point within the trigon. The customer can choose to optimize any two, but the third is dictated at its worst possible value. (The closer you move toward a property, the greater that property's value. At the points for Functionality, Cost, and Time, you have Maximum Functionality, Minimal Cost, and Minimal Time, respectively.) Of course, anyone who has ever done project management knows that you are always tasked to optimize all three.

Figure 2.1. The Project Management trigon

Functionality

Functionality is the principle that a system or component perform different tasks of relevance toward a goal.

As illustrated in Figure 2.1, functionality is a primary factor in making development trade-offs and the main factor governing many other principles in a system. It is no wonder, therefore, that developers want to develop the functionality first (by starting coding or by prototyping circuit boards of a system). To do this, they make many trade-offs, including sacrificing security. As the illustration indicates, however, functionality can be instituted in the early stages, but developers will pay later in time or cost, or both.

Utility

Utility is the principle describing the extent to which a system or component meets the goals established.

There is some debate about whether utility is any different from functionality in a development environment. We believe that it is, and the best way to explain the difference is with the following example. An engineer has to diagnose the logic within a microchip; the tool she has available is a Swiss Army knife. Although the knife has a lot of functionality, it does not offer much utility for the problem at hand.

Usability

Usability is the principle that a system or component be intuitive and simple to use.

For example, the first home DOS computers would boot to a prompt C:\> with a blinking cursor when turned on. To write a letter using a word processor, the user would have to change directories to the location of the word processor:

C:\> cd c:\progfiles\wp

Then, to start the program, the user would have to type another command:

C:\progfiles\wp> wp

The alternative was for users to learn how to change the path statement in the autoexec.bat file or create a batch file to perform the steps for them. In addition to this new step, they would have to learn the 8.3 character-naming scheme, thus making file management for today's average user nearly impossible. The learning curve to make these first machines useful was steep indeed.

Unfortunately, these usability issues are not just bad memories of the past. Today, you can find similar cases with palmtop devices that force the user to learn a new alphabet or cellular devices that require users to enter text from a numeric keypad.

Efficiency

Efficiency is the principle that a system or component use both internal and external resources effectively.

The priority of efficiency has changed greatly in the past few years. With PC memory and hard drive prices dropping, the recent past saw little need for efficient code. However, with the available real estate in mobile devices being offered at a premium, efficiency is increasingly higher on developers' priority list.

Maintainability

Maintainability is the principle that a system be easy and cost-effective for a user, or others on her behalf, to access and modify for upgrades, troubleshooting, and preventative maintenance.

For example, a particular model of a popular sports car manufacturer, which shall remain nameless, required that the engine be removed to change the rear spark plugs. This resulted in very poor maintainability. Owners had to pay for the labor and for parts such as gaskets and oil to have this procedure done at 15,000–20,000 mile intervals to maintain performance. Interestingly, rather than change the design, this manufacturer encouraged the development of new spark plugs that did not need to be changed for 100,000 miles, thereby increasing maintainability. Even though this solution would not have immediately come to mind for most people, it did increase maintainability. This also illustrates that there are many ways to obtain a satisfactory result when you keep an open mind about trade-offs.

Scalability

Scalability is the principle that a system be extendable or usable for an expanded customer base.

A good example would be that of a local telecommunications provider who advertised the ability to bring high-speed Internet service to area businesses without the need to run fiber-optic cable. Instead, it claimed to use wireless microwave from its network to the customers'. The architecture, although great in theory, was not as scalable as advertised. When the telecommunications provider tried to expand its service beyond a relatively small customer base, its wireless network was choked by the demand, and service was, shall we say, less than acceptable.

Testability

Testability is the principle that the requirements of the system be well-defined and specific so that tests can be created to prove directly that the requirements have been met.

A classic example would be a requirement that the system be easy to use. The phrase easy to use is meaningless without concrete, specific definition. How would you test this? How can testers know for whom it is supposed to be easy to use? (The requirements would be starkly different for a computer engineer than for a retired government clerk.) When it comes to security issues, we have seen requirements such as "the system shall be secure." Part of the process of ensuring that you have good and valid requirements is to determine how these requirements will be tested. Again, if the effort is placed up-front, there will be real benefit later in the development process and in the final product.


Management Principles

Four principles commonly describe the phases for evaluating a system's business aspects. They are Schedule, Cost, Marketability, and Margin. At the risk of losing some of the developers reading this book, we feel that we must cover these areas because looking at the security and development trade-offs without looking at the business aspects can encourage certain trade-offs that may adversely affect the ultimate system. These business concerns directly affect the security/functionality trade-offs made during design, development, and production. The biggest problem is that if the system is not properly designed at the beginning, the time and cost involved in retrofitting it to perform as desired can be overwhelming. Unfortunately, these trade-offs often come to light several stages into the project, usually at the testing phase. Our point is this: You cannot test functionality, security, or any other -ity into a system; it must be designed in from the start and carried throughout the entire process.

Schedule

Schedule is the principle that, to bring the project to completion, the system have a plan associated with the activities. A schedule relates resources to tasks and provides a means to manage resources in relation to time and effort. It also provides detailed resource requirements, including the number and type of resources for given parts of a project. A schedule also allows managers to determine critical points or milestones in the development process and ensure that the project is given adequate attention at these times.

Cost

Cost is the principle that the system have tangible costs associated with its development and maintenance (and exit strategy) and that these costs be known and linked to specific parts of the development. Knowing these costs enables managers to anticipate cash flow needs and capital expenditures as a project progresses.

Marketability

Marketability is the principle that the system have a consumer base, that there be a need for this product or service, and that the product or service have a differentiator to distinguish it in a positive manner from its competitors.

Margin

Margin is the principle, or more accurately, measure, that the product be sold for an amount greater than the costs associated with producing, distributing, and selling the product. This difference—between what a consumer is willing to pay for a given product or service and the cost to deliver that product or service—is the profit or margin.

Security analysis examines all these common principles and determines the best trade-offs to protect the system effectively while maintaining control over other principles of interest. To be complete and useful, any system analysis from a risk perspective must consider all these factors to determine overall risk. Many who claim to perform security, software, or some other form of risk analysis consider only portions of these principles. Security or software analysis cannot truly be useful unless all the principles are considered when recommendations or mitigations are provided.


The Security Analysis Process—I-ADD

At first glance, security analysis and planning can seem to be a daunting task. After all, countless books have been written and entire careers based on each one of these primary elements. How can all of them be analyzed simultaneously? Well, they do not have to be. Further, if the security analysis process is begun early in the project, particularly at the design phase, it is even easier because the analysis can follow, complement, and bolster the standard design process already in place. There are four phases to a successful security analysis process. We define this process as the I-ADD security analysis process, or "How I Add Security to a System." The phases are

1. Identify targets and roles.

2. Analyze attacks and vulnerabilities, generating mitigations and protections.

3. Define a strategy for security, mindful of security/functionality/management trade-offs.

4. Design security in from the start.

The key is that the I-ADD security analysis process is iterative and recursive. These two attributes enable you to perform a task that would otherwise be nearly insurmountable in scale.

Identify

The first phase in the process is to identify the system's high-level functional blocks. A typical wireless system has six high-level functional blocks (see Figure 2.2 for an example). After the high-level functional blocks are identified, an examination of each is performed with the intent of identifying the resource or information targets within each block that should be protected.

Figure 2.2. A typical wireless system

An alternative way to proceed through this process is to identify user roles in the block instead of the threats against it. If you are generating requirements documents, the former method is more useful in producing requirements that are testable. For instance, "The system must protect the user's credit card information" is better than "The system must protect against a malicious attacker who is monitoring the line and attempting to capture the user's credit card information."

The first stresses what must be protected, the credit card information, and the second stresses the role, a malicious attacker.

For a complete evaluation, you must look at both the targets and roles to be protected. A simple look at one or the other can cause a vulnerability to be placed in the system. For example, no "known" threat exists, so no protection in that area is provided. Conversely, excessive resources may be spent protecting a resource that is not vulnerable to a threat.

As you progress through the system, information may come to light identifying additional roles or targets that require protection for previous blocks. These items should be noted under the appropriate block as the process continues. After the first iteration is complete, the analysis is repeated until no more targets or roles deserving protection are identified. This concludes the high-level security analysis of the Identify phase.

Analyze

When the identification process is complete at the highest level, it is time to analyze the vulnerabilities and the known and theoretical attacks against the targets by the various roles identified. The goal of this phase is to develop an understanding of which items deserve additional resources to protect, which are "nice to have," and which can be placed on an "acknowledged, with no action necessary" list.

This phase is accomplished by

· Studying existing known attacks

· Comparing the system to other similar systems to analyze how vulnerabilities were mitigated and determining the appropriateness of using similar solutions with this system

· Examining current security and technological journals and Web pages for insights into the technology and research

· Developing an understanding of how potential mitigations will affect other aspects of the system

· Consulting experts in the field

The Analyze phase is closely tied to the next phase. When learning any methodology, it helps to consider each phase as a separate step, but practice and experience blur the lines between the phases.

Define

The Define phase takes the information from the previous two and defines or develops a strategy for implementing security in the system. This is where all the principles and factors are analyzed and, with that knowledge, trade-offs are made to provide the system with the necessary balance between all the elements defining and guiding system development. Usually, this phase is best approached as a team activity, with someone representing and concentrating on each major element of the system.

For example, a team may be composed of one or more (depending on the system's size and complexity) engineers representing development efforts, a security engineer, a project manager representing schedule, cost, user issues, and conflict resolution, and, last but not least, a facilitator who captures actions and ensures that the process does not become bogged down by conflicting priorities. The facilitator does not participate in the discussions. Done correctly, the strategy developed will represent a thoughtful analysis of the critical trade-offs between technology and business objectives and provide a roadmap for successful completion of the system.

Design

With a strategic roadmap in place, the system can be designed from the ground up, incorporating the features and procedures developed during the Define phase. The design should incorporate all the aspects of functionality determined appropriate in prior phases. If during this phase something comes to light that alters what appears to be reasonable, the process can be reiterated (hopefully at a rapid rate) to evaluate how this new information affects previous assumptions and recommendations. When the Design phase is complete, the resultant design specification and associated functional description should fully describe the system.

Figure 2.3 shows a graphical representation of the process. You enter the process at the Identify phase and iterate through the four phases until you have an acceptable design. Then you exit.

Figure 2.3. The security analysis process

Repeat

The next step in the process follows a recursive pattern in which each block is broken down to the next functional level. Figure 2.4 shows our typical wireless system with the wireless device broken down to the next functional level. The levels shown are just one possible way to break out the device.

Figure 2.4. A wireless system with the wireless device broken down to the next level

Each block at this level is then examined as a system unto itself, as illustrated in Figure 2.5 , just as the high-level blocks are examined using the I-ADD security analysis process. This recursion process is continued until the low-level software components are designed or the hardware components identified. The results are then returned up through the process, verifying that higher-level design requirements have been covered and incorporating any additional items identified in the lower levels.

Figure 2.5. A wireless system with the I-ADD process imposed on the second level of the wireless device


The Foundation

Before continuing, you should have a good understanding of the principles of security, development, and management. The security principles are Authentication, Access Control and Authorization, Nonrepudiation, Privacy and Confidentiality, Integrity, and Auditing. The development principles are Functionality, Utility, Usability, Efficiency, Maintainability, Scalability, and Testability. The management principles are Schedule, Cost, Marketability, and Margin.

You should also understand the I-ADD security analysis phases of Identify, Analyze, Define, and Design and that they are iterative processes that can be used recursively to divide a system into its basic functional blocks. These blocks are then analyzed, and the results are returned back up through the process until a complete system design or analysis is performed.

This provides you with the background necessary to understand the security issues covered in latter parts of this book. We will now be able to talk specifically about security issues of wireless systems and will go through the process described here on portions of actual wireless systems in use today. This chapter gives you an even foundation on which to build your understanding of wireless security.


Part II: Know Your System

Chapter 3. Technologies

Chapter 4. Devices

Chapter 5. Languages


Chapter 3. Technologies

Technology is the knack of so arranging the world that we do not experience it.

—Max Frisch

In the initial phases of developing a comprehensive security solution, you need to know the ins and outs of all components. Here we present detailed information on wireless technologies such as 802.11b, Bluetooth, and Wireless Application Protocol (WAP). Each technology occupies a different place on the wireless technology spectrum and has its own security implications. This chapter shows you what type of information you should understand about wireless technology by presenting the information necessary to know about certain technologies.


802.11 and 802.11b

In 1997, the Institute of Electrical and Electronics Engineers (IEEE) published the first world-recognized standard for wireless networks, 802.11. About two years later, the IEEE published 802.11b, also known as 802.11 High Rate, which specifies the standards for building wireless systems that operate with data speeds of up to 11Mbps. The intention of this standard is to give wireless networks the same robustness as that of wired Ethernet networks. One declared benefit of 802.11b is that administrators who design wireless systems to be seamlessly compatible with existing wired standards can follow the specifications of 802.11 with the assurance that the 802.11b standard will be backward compatible.

The basic features of 802.11b are defined by the existing 802.11 standards for architecture and services. The design paradigms are similar, and the components find parallels to the wired equivalent of 802.11b. The 802.11 standards provide specifications for the lower two levels of the Open System Interconnection (OSI) network reference model: the physical layer and the data link layer (see Figure 3.1). Any current application, network operating system, or protocol that exists in compliance with the 802.11 standards should be compatible with the wireless standards. These components reside in layers above the physical and media access control layers. Their operation is not affected by differences in the lower layers. To understand 802.11b, you must understand the building blocks of the 802.11 standard.

Figure 3.1. The OSI model

802.11 System Components

The 802.11 regulation sets definitions for two categories of equipment: a station and an access point (see Figures 3.2, 3.3, and 3.4). The wireless station is any standard PC that has a Network Interface Card (NIC) that supports wireless communication. The station has access to the wireless medium and radio contact to an access point. The access point is the equipment that allows the wireless system to interact appropriately with a wired one; in other words, the access point performs an important function called bridging. A typical access point comprises a radio, a wired network interface, and bridging software conforming to the IEEE bridging standard. The access point can be pictured as a base station for the wireless system. Communication for many wireless stations is funneled to the access point and directed to the wired network.

Figure 3.2. The BSS infrastructure mode

Figure 3.3. The ESS infrastructure mode

Figure 3.4. The BSS ad hoc mode

802.11 Architecture Modes

The wireless stations and access points are configured in two modes as defined by the specifications: infrastructure mode and ad hoc mode. In infrastructure mode, all stations in a system connect to an access point, not directly to one another. In ad hoc mode, the stations interconnect directly, without communicating through an access point.

Infrastructure mode comprises access points and stations in the same radio coverage that form a basic service set (BSS), illustrated in Figure 3.2. Several basic service sets connected form a distribution system, creating one larger network and extending the wireless coverage area. This distribution system is called an extended service set (ESS). The 802.11 specification does not further detail the architecture of a distribution system. The individual implementations are left up to system architects. Decisions about how to interconnect BSSs are based on design requirements, types of stations or devices, and business considerations. If interconnection with wired systems was a requirement in building a wireless system, infrastructure mode specifications would provide direction for a viable system. Handoffs can occur between BSSs to extend network capabilities. Alternatively, the access points in several BSSs can be connected to a wired LAN, further extending its capabilities.

An architecture in ad hoc mode is a set of stations that communicate without an access point (see Figure 3.4). This on-the-fly mode does not require connection with a wired network and is easily assembled and disassembled. Each node communicates with the others directly. In ad hoc networks, however, possibilities for interconnecting with other wired or wireless networks are limited in that there is no master/slave relationship and each station maintains its own independence. As in infrastructure mode, interconnected stations form BSSs. 802.11 does not specify routing paradigms, data forwarding, or exchanging topology information among BSSs.

802.11b Physical Layer

One of the most valuable additions the 802.11b standard provides is the standardization for the physical layer support of two new speeds, 5.5Mbps and 11Mbps. The 802.11 standard specifies two signaling methods, with data rates of 2Mbps and 11Mbps and operation in the 2.4–2.4835GHz frequency band: frequency-hopping spread spectrum (FHSS) or direct-sequence spread spectrum (DSSS). The two are not interoperable. In FHSS, the band is divided into many subchannels. The receiver and sender, with the intent of minimizing the chance that two senders will simultaneously use the same subchannel, decide on a hopping pattern. Subchannel bandwidth cannot be greater than 1MHz, as regulated by the FCC. These regulations restrict the maximum usage and lead to high hopping costs. At the same time, however, 802.11b is less susceptible to multipath propagation interference than 802.11.

The DSSS technique, however, allows for most subchannels to overlap slightly. Data is sent over channels without hopping. A technique called chipping is used instead. Much like file compression, this technique allows bits of user data to be converted into a series of redundant bit patterns, called chips. The redundancy and spread of chips across the entire channel facilitate error checking and correction. Retransmission is rarely necessary, even if part of the signal is damaged.

The value added by the institution of the 802.11b standard is realized in the standardization for the physical layer support of the two new higher speeds, 5.5Mbps and 11Mbps. In the 802.11b specifications, DSSS is the sole signaling method supported. FHSS is eliminated in this new standard because it cannot support higher speeds without violating FCC regulations. The intention for 802.11b DSSS use is that it interoperate with existing 1Mbps and 2Mbps 802.11 DSSS systems but not with 802.11 FHSS systems.

To increase the data rate in 802.11b, advanced coding techniques are described. In the previous standard, 11-bit Barker sequences (an 11-bit chipping) encode all data sent over the air. Each Barker sequence is converted to a waveform and sent over the air. The waveforms, called symbols, are transmitted at 1MSps (a million symbols per second) in a 1Mbps DSSS system and are doubled in the 2Mbps systems. In the 802.11b standard, rather than use the 11-bit Barker sequences, a Complementary Code Keyring (CCK) is specified. This CCK enables the symbol rate to be increased to 1.375MSps.

802.11b uses dynamic rate shifting to achieve the maximum data rate, even in cluttered environments. Data rates are automatically adjusted to make the best use of the 11Mbps rate. When high interference is present or a wireless device is moved outside the best range for 11Mbps, the rate is shifted to a slower speed (5.5Mbps, 2Mbps, or 1Mbps). The dynamic rate shifting automatically bumps to a higher speed when moved back into appropriate 11Mbps range or when the interference sufficiently subsides.

802.11 Media Access Control Layer

The 802.11 Media Access Control (MAC) layer is designed to support multiple users on a shared medium by having the sender detect and gather information about the medium before accessing it. The 802.3 Ethernet-based (wired) LAN specification is also designed to support multiple users on a shared medium and specifies methods for the sender's sensing the medium, however the protocol employed (Carrier Sense Multiple Access with Collision Detection [CSMA/CD]) details collision handling and redirection. In 802.11, collision detection is not possible because stations cannot listen and transmit at the same time; the radio transmission prevents the station from sensing a collision. The protocol specified is slightly different from that in 802.3; it is termed Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). CSMA/CA involves sending extra packets to confirm receipt of transmitted packets, called explicit packet acknowledgment (ACK).

In a proper CSMA/CA transmission, the sender senses the medium, and if no collisions are detected, it waits a randomly defined period of time and, if the medium is still free, transmits to the intended recipient. When the recipient has received the sender's entire transmission, it returns an ACK frame. The process is successfully complete when the sending station receives the ACK frame. If the ACK frame is not received by the sending station, either because the original transmission was not received or because the ACK frame was unable to transmit successfully, a collision is assumed, and the data packet is retransmitted after another randomly defined period of time.

CSMA/CA effectively handles transmission and collision problems associated with radio communication. It does not provide for minimization of overhead, however, and renders 802.11 communication slower than that of 802.3 by necessity. Simply put, wireless communications are slower than wired communications.

Another protocol defined at the MAC layer is an optional Request to Send/Clear to Send (RTS/CTS) protocol.

Unfortunately, accompanying each benefit is a caution. The 802.11b standard was developed to be seamlessly compatible with the existing IEEE wired standards but has been criticized as being too compatible. Because the standard's security requirements are compatible with a wide range of devices, networks, and other technologies, the standard in its basic form leaves potential systems wide open.

The standards dictate what should be possible—that the application layer and network protocol layer not be affected by these differences at a data link or physical layer—but they do not operate seamlessly without risk.

802.11b Security and Wired Equivalent Privacy (WEP)

The goal of securing wireless network traffic is to approach as closely as possible the security offered in wired networks. The 802.11b standard affords this possibility by way of the Wired Equivalent Privacy (WEP) protocol. WEP offers communication encryption and physical device authentication capabilities to wireless communications while balancing users' needs for privacy with ease of use. WEP is available in 64-bit and 128-bit strength. In wired LANs, stealing network traffic is considered difficult because an attacker needs to be in close physical proximity to the network to gain access. The attacker has to be close enough to a network cable to use listening equipment to intercept waves emitted as data flows though the network. In wireless networks, however, the same attacker does not need to be physically close to a cable but can simply be in a parking lot adjacent to the building where the wireless LAN is installed.

The WEP protocol algorithm is designed on five premises:

1. Reasonably strong. Takes a reasonably long time to crack the encryption.

2. Self-synchronizing. Resynchronizes connection among devices when communication is inadvertently terminated.

3. Computationally efficient. Is not too taxing on battery power.

4. Exportable. Can be moved among media when necessary.

5. Optional. Can be turned on and off at a user's discretion.

The protection provided by the WEP algorithm is all some mobile users require. It automatically synchronizes itself between the device and the access point. This is helpful because wireless stations frequently drop communications or vacillate in and out of service, depending on their distance from an access point and the strength of the signal. The algorithm is efficient and can therefore be implemented in software or hardware. It can be exported under current U.S. government regulations and is optional in an 802.11 system.

The process is as follows (see Figure 3.5):

Figure 3.5. The WEP authentication sequence

1. A requesting station sends an Authentication frame to the access point (AP).

2. When the AP receives the initial Authentication frame, it replies with an Authentication frame containing 128 bytes of random challenge text generated by the WEP engine in standard form.

3. The requesting station copies the challenge text into an Authentication frame, encrypts it with a shared key, and sends the frame to the responding AP.

4. The receiving AP decrypts the value of the challenge text, using the same shared key, and compares it to the challenge text sent earlier. If a match occurs, the responding station replies with an authentication indicating a successful authentication. If not, the responding AP sends a negative authentication.

Most businesses that choose to use 802.11b wireless LANs, however, should not rely on WEP alone. In spring 2001, WEP encryption was determined breakable by researchers at the University of California, Berkeley and at the University of Maryland. The papers produced by these two groups of researchers outlined the weaknesses inherent in the creation of keys used in the encryption algorithm for encrypting traffic traversing the wireless network. Throughout the rest of the year, different groups implemented the attack with collections of WEP data, and some released tools to facilitate the encryption break.

The encryption algorithm itself is not the problem. The vulnerability lies in the keys used in the encryption algorithm, which render it relatively easy to break. The mechanism used to generate the keys creates keys that are too closely related to one another. With enough wireless data packets captured, you can easily determine keys to use to crack encryption. With the ability to crack the encryption code, all data passed on a wireless network becomes viewable, and you have successfully pried the network wide open.

Often, the wireless access point installed in an office is placed inside the corporate firewall, opening the entire network to attack. Wireless network attacking is very difficult to detect because the attacker needs only to conduct a passive attack to gain access to the system. Merely by listening to packets as they fly through the air, an attacker can execute her break. Two applications that can be used to break into a wireless network, AirSnort and WEPCrack, can be used to implement the findings published by the California and Maryland researchers. These applications boast being capable of resolving a network's WEP keys within seconds of listening to network traffic. With the introduction of these applications, any high school student with a laptop and a wireless network card, regardless of her knowledge of technical details, can break in to wireless systems.

The weakness of the WEP encryption implementation is not the only one in 802.11b. There is another concern, which should garner more attention than it does. Most wireless access points and networks are being deployed without the limited defense of WEP encryption being enabled.

Wireless networks configured merely by plopping an access point into an existing secure wired network should be deemed insecure. Wireless access points should be used only with the knowledge that they introduce gaping holes into a system by nature. They can be used, but only after certain precautions are taken. In December 2001, an IEEE committee approved an interim patch for WEP that thwarts the success of applications like AirSnort or WEPCrack and other homegrown varieties of WEP encryption breakers. It is more prudent, however, to consider WEP a weak protection against attack. Access points should be treated like Internet traffic—with great caution. They should be placed outside firewalls and routed through Virtual Private Network (VPN) solutions in all cases. Basically, networks should not rely on the security provisions that come with 802.11b out of the box. Firewalls and VPN solutions protect the problems described here just as they protect wired systems.

In late 2001, RSA released a solution to the weakness present in WEP, the Fast Packet Keying solution, which uses a technique that rapidly generates a unique key for each wireless data packet. The IEEE committee approved this fix in early 2002. Although it quells the war-driving experiments of many, it does not solve wireless LAN security problems indefinitely. Claims were made that this solution solved the weakness inherent in wireless communication using WEP. These claims are valid, but many wireless security proponents now believe that a more advanced encryption mechanism and key generation scheme should be used.

Until subsequent versions of 802.11 and WEP are secure, external security measures are absolutely critical. Almost no security is offered at the data link layer. It is safe to assume that if any wireless access points are placed inside a firewall on a corporate network, anyone within physical range of your wireless network can act as a legitimate user on that network. Although 802.11 is the most popular technology, there are other competing and complementary technologies, such as Bluetooth.


Bluetooth

Unlike 802.11, Bluetooth is a technology that operates solely in ad hoc networks. Infrastructure mode is absent from Bluetooth discussions, as are long ranges among stations. Interestingly, Bluetooth gets its name from a Danish Viking king named Blatand, who was king of Denmark around the late 900s. He was responsible for Christianizing Denmark and uniting it with part of Norway. His name indicates nothing about the technology but rather signifies the importance of countries in this region of the world in the wireless industry. In 1998, a little more than one thousand years after his death, five companies, following Ericsson's lead, founded the Bluetooth consortium. These companies, including Intel, IBM, Nokia, and Toshiba, directed the development of Bluetooth specifications with the intention of Bluetooth's being a low-cost wireless transmission standard. Many more companies joined what is now termed the Bluetooth Special Interest Group (SIG); the membership totals around 1,000.

Bluetooth is a de facto standard, as well as a specification for small-form factor, low-cost, short-range radio links among devices. The Bluetooth SIG drives the development of the technology and is attempting to push it to the general telecom, networking, and computer industry markets.

The Bluetooth SIG goal is to integrate Bluetooth in everyday devices, not just cell phones and laptops. SIG operates under the premise that adding Bluetooth technology to a device should increase its cost by only $5 or so. Bluetooth should be capable of functioning in such basic implements as a pen and such complicated devices as a computer or PDA. Bluetooth spares expensive wiring and infrastructure costs but does require stations to be within close proximity of one another to communicate. It enables devices to interoperate with an approximate range of 10 meters. The Bluetooth SIG members intend for Bluetooth to be the dominant technology for connecting all consumer electronic devices. They envision the use of Bluetooth to connect a cordless handset to its phone, a peripheral to a computer, a PDA to a computer, two PDAs to each other, or perhaps even a remote control to a TV via a computer.

In general, devices similar to Bluetooth, which use infrared (IR) as a transmission medium, are reliable, and building the technology into a device requires little cost. These devices do, however, require a line of sight between them, which significantly limits their versatility. Bluetooth itself does not have this same line of sight restriction because it operates over radio instead of light, like other IR-capable devices.

Bluetooth Physical Layer

Bluetooth uses the 2.4GHz frequency band with a frequency-hopping scheme for transmission at a rate of 1,600 hops per second. The 2.4GHz frequency represents the range assigned by international agreement as the communications spectrum for industrial, scientific, and medical (ISM) devices. More familiar devices that operate in the ISM band include baby monitors, garage-door openers, and certain cordless phones.

One method some Bluetooth advocates see as a way to avoid Bluetooth devices' interfering with one another's communication is its frequency-hopping technique. This technique is similar to that employed in the 802.11b standard. The time between two hops in Bluetooth transmissions is called a slot. Each slot utilizes a different frequency, and each device hops among the 79 randomly chosen frequencies. In some countries, the available bandwidth is only 80MHz. In these countries, the hops are spaced out in 1MHz intervals of equal proportion. In countries with smaller bandwidth allowances, where regulations allow only 23 hop carriers, the frequencies are less spaced out from each other. Bluetooth transmits a weak signal, only 1 milliwatt. The most powerful cell phones transmit at about 3 watts. The low power dictates the short 10-meter range from which Bluetooth devices can communicate. The low power combined with frequency hopping is its native protection against security breaches and communication interference. Later in this book, flaws in this theory are discussed, as well as risks.

The Bluetooth technology is structured in ad hoc piconets, networks with two or more devices that don't require infrastructure frameworks (see Figure 3.6). In a Bluetooth piconet, devices are designated master or slave. In any given communication session, a device has the potential to be either a master or a slave. The default method for determining the master is that device which initiates a connection. As many as seven devices can be designated slaves to each master. In some special circumstances (for example, Bluetooth's implementation of profiles, discussed later in this section), devices may need the capability to toggle between master and slave. In such cases, master/slave switch operations have to be added to the basal devices.

Figure 3.6. A piconet

To establish a piconet, an initial device (by default, the master) must first initiate contact with a slave. If the master already knows the address of the intended station, it transmits a page message. This message simply alerts the potential slave that the master wants to connect and establish a communications link. If the master does not know the slave's address, it must first send an inquiry message to determine the station's address. The message requests the slave's MAC address and, after retrieving the information, transmits a page message.

The master in a Bluetooth piconet defines its frequency-hopping sequence. This frequency hopping is similar to the FHSS examined in the 802.11b section. The frequency hopping in this instance, however, is designed to reduce the likelihood of transmissions from one piconet impeding those of a neighboring piconet. It is possible for a master to address a specific slave with its communication and not broadcast a transmission to any active slaves in its piconet. This type of interaction is typically called point-to-point communication. If a master broadcasts a transmission to all active slaves in its piconet, this is termed point-to-multipoint communication. Slaves cannot initiate either type of communication. Slaves cannot even initiate communication with each other. A slave device would have to depart from its current piconet and begin another as a master, at which point it could contact another slave directly from the previous piconet (if that slave, too, has left the original group).

Recall that in 802.11, BSSs could be joined to form ESSs. This network expansion finds a parallel in Bluetooth as well. Piconets can join to form scatternets (see Figure 3.7). For BSSs to expand to ESSs, they must interconnect through an infrastructure, a connection to a similar access point or wired network. In Bluetooth, however, one device that is a member of two would-be joined networks must be simultaneously a slave and a master. This device is an active participant in more than one piconet. The Bluetooth consortium has identified several parameters for the existence of scatternets.

Figure 3.7. A scatternet

In a scatternet, there may be only ten fully loaded piconets (recall that a piconet can contain one master and as many as seven active slaves). If more than ten piconets are connected, communications can be damaged arbitrarily among any devices or piconets. Derivatives of this rule stipulate further limitations. A single device may link two or more piconets into a scatternet. A single device may act as a master in, at most, one piconet but as a slave in (as many as) the other nine. The safest and most common configuration for any given device is designated as a master of one piconet and a slave of another. When a device becomes a slave in more than one piconet, its role becomes increasingly problematic in that it must maintain the clock values of multiple masters. Coordinating these clocks is extremely difficult, and the Bluetooth specifications do not lend themselves to multiple-slave designations.

A limitation in the Bluetooth specifications themselves is that they are general and lacking in architectural and application-level recommendations. This generality makes application development and, subsequently, development of provisions for security exceedingly troublesome. For more technical information about Bluetooth, please see the Bluetooth specifications. For security concerns, the concepts outlined here provide ample grounds on which to identify risks and construct their mitigations at various levels.

Bluetooth Protocol Architecture

The Bluetooth SIG has identified and described core protocols for Bluetooth architecture systems. These protocols are designed to be used in conjunction with existing protocols used in other 802.x systems. The Bluetooth SIG defines four core protocols, as well as several others that support Bluetooth communication. The four core protocols are

1. Baseband and Link Control (BLC)

2. Link Manager Protocol (LMP)

3. Logical Link Control and Adaptation Protocol (L2CAP)

4. Service Discovery Protocol (SDP)

The BLC layer enables the combined physical links to form a piconet. This layer assists in organizing the frequency hopping by using page and inquiry messages to determine the best path available. Two types of physical links are available to Bluetooth devices: Asynchronous Connectionless (ACL) and Synchronous Connection-Oriented (SCO). In ACL mode, communication is faster because the device is either transmitting or receiving data at any one time and functions only with data packets. In SCO mode, a device can be transmitting and receiving at the same time and can use either audio or data packets. The audio and data packets can be encrypted and can use different levels of error correction.

The LMP layer establishes the physical links and manages encryption or authentication by negotiating baseband packet sizes and exchanging and checking link and encryption keys. The LMP also maintains the connection state of a device in a piconet.

The L2CAP layer operates in higher protocol layers than the BLC. It provides data services, both connection-oriented and connectionless, to the upper-layer protocols with the capability to partition data for sending and reassemble it upon receipt. L2CAP is defined only for ACL links; no support for SCO links is specified by the Bluetooth Specification 1.0.

The fourth core protocol defined in Bluetooth is particularly interesting. The SDP layer fosters the creation of Bluetooth usage scenarios. Bluetooth advocates tout SDP as extremely easy to use when you want to communicate with another Bluetooth device. SDP provides device information, services available, and specific information about querying services so that a device connection can be established. If SDP is configured in what is called discoverable mode, Bluetooth devices are available for other devices to detect. The intended usage model is that two people point their PDAs at each other and instantly communicate. The critical flaw in this example is the assumption that both users want to communicate with each other.

Immediately, security-minded professionals should be able to conceive of hundreds of situations in which this ease of connection is a distinct hindrance to security and privacy. If Barbara is taking the train from New York to D.C. and falls asleep with her Bluetooth-enabled PDA on her lap, she doesn't want Karen, the technical rep from her firm's biggest competitor, simply pointing her own Bluetooth-enabled PDA at Karen's and "communicating" unbeknownst to Karen. If Tom approaches a vending machine and is about to make a phone call on his Bluetooth-enabled cell phone, he doesn't want the vending machine to deduct 50 cents from his checking account simply because there was a direct line of sight between the Bluetooth-enabled cash handler in the vending machine and his cell phone.

These situations represent every security-conscious individual's worst nightmare. The likelihood that they will come to fruition is, as of yet, unknown. Attempts will be made. Of that we can be certain.

Other protocols implemented in a Bluetooth stack are

· Cable Replacement Protocol. Provides transport capabilities for upper-level services.

· Telephony Control Protocol—Binary. Defines signaling for data and speech calls.

· Telephony Control Protocol—AT commands. Defines fax and modem use in Bluetooth devices.

· A set of adopted protocols (PPP, TCP/UDP/IP, OBEX, WAP). Allows Bluetooth to interoperate with applications that reside in still higher layers on the protocol stack.

For more information on these protocols and Bluetooth's use therein, see the Bluetooth Specification 1.0.

Bluetooth Profiles

Bluetooth is designed to be specific at the lower layers of a protocol stack and more flexible and interoperable at higher levels. The physical and data link layers define Bluetooth's unique characteristics and operations. The Bluetooth SIG has developed several profiles to be used in assisting Bluetooth application development. These profiles are intended to capitalize on Bluetooth's features, as well as enable it to operate with other systems. One Bluetooth profile available enables developers to integrate WAP-compatible applications with Bluetooth devices.

Current SIG working groups are working on a profile to allow Bluetooth devices to be routable. Should this profile be approved and implemented, the 10-meter distance limitation could be eliminated. In this intended profile, if a user is more than 10 meters from an access point but within 10 meters of a user who is closer to the access point, the transmission from the first user can be routed through the second to the access point and back. This profile has not yet been published, so the relative security of the routing cannot be assessed. Assumedly, this could present many dangers. The second user, who is functioning as a router, must be open to receiving traffic and potentially has access to it, given the right equipment and applications.

Another profile worthy of note is the Generic Access Protocol. It is discussed next because it is inextricably linked to discussions of Bluetooth security.

Bluetooth Security

The LMP in the Bluetooth protocol stack handles link-level authentication and encryption mechanisms. These features are based on a shared secret between two devices. This shared secret key is supposedly generated the first time two devices forge a connection and communicate. Bluetooth profiles describe how to use the functions built in to the LMP and BLC protocols compatibly with other non-Bluetooth devices. Three security modes are possible under the instruction of the Generic Access Protocol:

· Security Mode 1. Non-secure. The device does not automatically initiate any security procedures.

· Security Mode 2. Service-level enforced security. The device does not automatically initiate security procedures before the L2CAP layer establishes a channel. This level facilitates ease of interaction with applications that have varied security requirements.

· Security Mode 3. Link-level enforced security. The device initiates security procedures before the link is established at the LMP level.

It almost goes without saying that mode 1 security is a poor solution for any operations or applications that require even the beginnings of security. For the purposes of this text, Security Mode 1 will be disregarded. Bluetooth recommends that either of the other two be implemented in designing Bluetooth architectures and applications. Security Mode 3 is more straightforward than Security Mode 2 in that it initiates security procedures before the link is established. Security Mode 3 does not allow for as much flexibility, so it may not be used as often in systems designed to accommodate different devices, applications, and topologies. Security Mode 2, therefore, provides the most salient topic for examination of Bluetooth security. This mode allows system architects and developers to construct security paradigms and requirements without eliminating the possibility of integrating with devices and applications that have different security requirements.

Before discussing security design paradigms in Bluetooth systems, several points need to be established. In Bluetooth's base form, its technology and specifications do not include inherent security functionality. Options for designing implementations do provide for more secure methods of protecting devices, applications, and architectures. However, each option requires significant expertise on the part of system architects and application developers.

You can design and produce an application without security features, to be used with Bluetooth-enabled devices. A device left configured at mode 1 security, for instance, with no additional security implemented, is wide open to attacks at many levels. A device with mode 2 security, however, can be constructed to limit the risk posed to its users.

Finally, it is important to note that the security paradigms set forth here are merely options available and are intended to provide guidelines for establishing appropriate security architectures in other wireless systems. A wireless architect would be remiss if he did not examine his system with respect to the security procedures explained in Chapter 2, "Security Principles." The system must be dissected before appropriate security methods can be determined. That said, the Bluetooth specifications do not provide for security design suggestions but do provide the foundation on which to build relatively secure systems and communications.

There are two types of relationships between devices. In the first type of relationship, devices can be configured to always trust and recognize each other, perhaps including unrestricted access to each other's available resources. Your cell phone, for instance, can be configured to always recognize and authenticate fully with your PDA and laptop. The second relationship type requires periodic or repeated authentication between your device and others because they do not operate under the same patterns of trust as yours, for instance. This second relationship between devices establishes nonpermanent trust. Access to services on these devices is restricted and subject to consideration for different contexts and resources. The choice between the properties of trust and nonpermanent trust is more or less appropriate in different system configurations.


WAP

The Wireless Application Protocol (WAP) is considered by some to be the standard in wireless communications. WAP specifications were developed by members of the WAP Forum. (Those who sit in opposition to the assertion that WAP is or will become the standard in wireless communications find themselves on the WAP Is Crap bandwagon.) The WAP Forum was started by Phone.com (then Unwired Planet, now Open Wave) and joined shortly thereafter by Nokia, Ericsson, and Motorola. Although its pricey admission fee of $27,500 did prevent other companies from initially investing in the development of the WAP standard, the WAP Forum is open to any group that pays the admission fee. Currently, there are nearly 1,000 members, including a variety of smaller companies representing different interests from those of the four founding members.

There is great debate in the development community whether WAP, because it is a protocol standard like 802.x, should be open for comment and criticism from individuals other than members of the WAP Forum. Still, the members keep their doors closed to outside comments. WAP is in its early stages, with planned updates to be released periodically over time. Whether its critics are right and whether it does succeed, WAP is a technology that has had and will continue to have an effect on the wireless industry.

The WAP Forum published this global wireless protocol specification based on existing Internet standards, such as XML and IP, for all wireless networks. WAP is primarily used in Europe, although it sees a small penetration in U.S. wireless markets. More than 75 percent of cellular phones are shipped with it worldwide. Fewer wireless-enabled PDAs, however, implement WAP than cell phone manufacturers. This could be due, in part, to the main products produced by the founding members of the WAP Forum or could be merely coincidental.

Several components of WAP are essential to understanding its security features and limitations. First is its protocol stack. WAP functions higher on the protocol stack than does Bluetooth or 802.11b. Because these three technologies do not function at the same level, drawing salient parallels among the three is difficult. In wireless markets, however, these three are the forerunners in the race for the most pervasive wireless system paradigm.

After studying WAP's protocol stack, it is imperative that you become familiar with the workings of WAP architecture. Its devices, languages, gateways, and networks lend insight into how to best prepare a system for protection against its security limitations. First, we will examine the protocol stack, shown in Table 3.1.

Table 3.1 illustrates a mapping between wired Internet components and WAP components. Although the WAP stack is, in large part, derived from the ISO OSI reference model, it describes only five layers to the OSI model's seven. It is similar to the Web or Internet model, as shown in Table 3.1. The WAP specifications define each layer of the protocol stack by designing mechanisms that facilitate communication from smaller devices through slower connection speeds over networks with high degrees of latency, with the intent of enabling them to integrate with other wired infrastructures.

Table 3.1. The WAP protocol stack

Functionality

Internet

WAP

Application layer

HTML

JavaScript

Wireless Application Environment (WAE)

WML, WMLScript

Session layer

HTTP

Wireless Session Protocol (WSP)

Transaction layer

HTTP

Wireless Transaction Protocol (WTP)

Security layer

TLS-SSL

Wireless Transport Layer Security (WTLS)

Transport layer

TCP

UDP

Wireless Datagram Protocol (WDP)

User Datagram Protocol (UDP)

Network layer

IP

Bearers: GSM, SMS, USSD, GPRS, CSD, CDPD, etc.

The top layer in Table 3.1, the Wireless Application Environment (WAE) , provides a framework for the development of portable applications and services. The WAE provides residence for WAP's native languages: the Wireless Markup Language (WML) and its partner script, WMLScript. The two languages are based on ECMA script (a predecessor to JavaScript) and are designed to allow development in small chunks to save costly transmission time. Both languages are discussed in further detail in Chapter 5, "Languages."

The next lower layer in the protocol stack is home to the Wireless Session Protocol (WSP). This layer provides definition for exchanging content by way of sessions between clients and servers. In the Internet realm, this is handled by HTTP. HTTP also handles the transactions in wired network applications, but in WAP, transactions are handled by the Wireless Transaction Protocol (WTP). WTP offers several methods by which devices can perform transactions; variations among methods are mostly in degree of reliability.

Of particular interest is the Wireless Transport Layer Security (WTLS). This wireless equivalent to Transport Layer Security (TLS) or Secure Socket Layer (SSL) provides authentication, privacy, and secure connections between applications. In WAP specifications, as in Internet communications, this layer is optional. The problem with WTLS is that it does not provide end-to-end security, as might be expected. At a certain point during a communication cycle structured according to WAP specifications, a server, called a WAP gateway, has to decrypt the WTLS packets and encrypt them in TLS or SSL to transmit them securely across network channels that follow wired Internet specifications. For an instant, that information resides in the clear on the gateway and is vulnerable to attack.

The next lower layer in the WAP stack is the transport layer. The Wireless Datagram Protocol (WDP) serves as a divider between the upper layers of the protocol stack and the bearer services provided by the service operator.

WAP Overview

The easiest way to explain WAP is to follow a communication cycle. This example describes how a user with a WAP-enabled cell phone can execute an application that runs via a server-side script on a standard Web server. Figure 3.8 illustrates the process. The user presses a key on her phone that has an assigned URL request. The user agent on the phone sends an URL request to a WAP gateway in the form specified via WTP. The WAP gateway receives the request and translates it into an HTTP request for the same URL. If the transmission is sent using WTLS, the gateway also translates the data into HTTPS. The gateway forwards the HTTP or HTTPS request for the specified URL to the Web server. The Web server processes the request. If the URL refers to a static file, the Web server retrieves that file. If the URL refers to a script application, however, the Web server runs the application and returns its output. This completes one half of the communication cycle. Now the data begins its return trip to the phone.

Figure 3.8. WAP architecture

The Web server passes the requested file or output, along with any HTTP or SSL headers, via HTTP back to the gateway. Again, the gateway performs translations. If the returned information is in a language readable by the phone (in this case, WML), the data is simply forwarded. If the data is in HTML or another language not readable by the phone, a translation server must translate the information into WML. Sometimes this translation is performed on a server other than the gateway, and other times it is performed by the gateway itself. (The search engine Google, www.google.com, currently searches all HTML pages and performs the translation for the user. Other wired Internet engines currently search only the smaller subset of Web pages coded in WML and do not perform translations on behalf of mobile device users.)

Another translation may occur on the WAP gateway when the data is sent via SSL. In this case, the WAP gateway decrypts the SSL-encrypted data and encrypts it in WTLS standard. After the appropriate translations are performed, the WAP gateway verifies the WML content and encodes it, along with companion HTTP headers, into a binary form. This binary form serves one purpose: to minimize bandwidth usage. Now the gateway sends the data as a WAP request over WTP via bearers, finally ending at the phone.

After the phone receives the WAP response, it begins another set of conversions. It parses the WML response and displays the first card of the WML deck on the phone's display screen.

Wireless Application Environment (WAE)

The application environment is the only place security can be anchored with any strength in wireless systems. The WAE is where this must take place in a WAP architecture. The WAE gives developers the tools to construct applications suited for small, limited platforms and wireless communication. Two user agents on the devices compose the WAE: The WAE user agent includes the microbrowser and the text message editor, and the Wireless Telephony Application (WTA) user agent is responsible for the receipt and execution of telephony functions.

The WAE specifications do not provide guidance on implementation or design of user agents. They simply offer formats that can be used for images or text messages with which user agents must comply. The different components of a user agent can vary greatly among manufacturers of both devices and software resident on those devices.

When exploring the WAE, assessing its languages and their potential security risks is important. WML and WMLScript are investigated in greater detail in Chapter 5. In brief, WML is analogous to HTML and based on XML. It uses a deck of cards metaphor. Instead of pages, as they are called in HTML, contained slices of WML are called cards. Each card contains a small amount of text or data to provide smaller chunks of information that need to be displayed at any given time. A group of cards that are packaged together for transmission is called a deck. The encoded WML sent to a user agent from the WAP gateway is decoded into a deck of cards for display to limit network roundtrips.

WMLScript is based on ECMAScript (the same language on which JavaScript is based). WMLScript enables WML to offer value-added services. WMLScript provides the functionality to validate user input and access local functions in a wireless device (for example, WTAI) and supports local messaging in the form of alerts or errors resident on a device to save communication time. WMLScript supports six standard libraries, which are explained in Chapter 5. WMLScript is called via URLs and is not embedded in WML, as in <a href="calling.wmls#calculate(2,3)">. No type checking is done at either compile time or runtime, and no variable types are explicitly declared. WML/WMLScript developers can and must develop their own libraries to maximize the capabilities of these minimalist languages.

Another significant component of the WAE is the Wireless Telephony Application (WTA). The WTA provides access to the phone's telephony facilities, allowing service providers to accept and initiate calls, send and receive text messages, add, search, and remove phonebook entries, examine call logs, send tones during calls, or press keys on a keypad during a call. It allows the Internet to access mobile phone functionality resident either on the client itself or in the mobile network. A framework for WTAs allows access to telephony functionality from within WMLScript applets. This enables operators to develop secure telephony applications integrated into WML/WMLScript services. For example, services such as call forwarding may provide a user interface that prompts the user to make a choice between accepting a call, forwarding it to another person, or forwarding it to voice mail.

Each of the telephony features appears attractive to would-be attackers of wireless systems. To protect against the dangers of unauthorized use, WTA services assume that users will visit only trusted WAP gateways, where they then connect to WTA servers. The WTA servers regulate the WMLScript functions that can be passed to a device that accesses WTA functions and stores the libraries used to invoke WTA functions. These servers are controlled by wireless operator networks and are assumed to be trusted.

The WTA and WAE specifications do not dictate any native security on the mobile device beyond this minimal precaution. If a WTA server or WAP gateway was compromised, the regulation of WTA functions for phones would be inept and would leave all devices communicating through the system open to compromise. It would be possible for scripts to erase phonebooks, steal phonebook data, place unwanted phone calls, or otherwise tamper with telephony functions. The Wireless Telephony Application Interface (WTAI) facilitates the interoperation of the WTA user agent with either the telephony functions residing on the device itself or those housed on the wireless operator's network.

Another security precaution inherent in WTA specifications is that the device manufacturers (both hardware and software) appropriately assign permissions for scripting on the phone. Three permission types are available to access WTA functionality:

1. Blanket permission to access all functions within a WTAI library

2. Context permission to run a given WTA function within the current execution context

3. Single-action permission to access a given WTA function once

The WAP specifications do not require these permissions to be established or configured at a certain point in the creation of a device or application. Caution in its implementation is left up to developers. WTA specifications do not even specify default settings, so if left unconfigured, the telephony functions appear wide open. The settings are potentially determined by the wireless service provider. If history is any indication, service providers will preconfigure devices with liberal permissions to permit access to their own scripts without regard for other potentially malicious scripts.

To understand the role of WTA and WTAI more clearly, it is helpful to step through a communication procedure. When there is a need to access a WTA function, the WTA user agent on the mobile device sends a request to the WAP gateway with the name of the library and specific function desired. The gateway then solicits help from the WTA server to obtain the requested function and determine permissions for its use. After receiving a response from the WTA server, it forwards the appropriate code back to the WTA user agent on the mobile device. On the device, the code is run when the WTAI allows it to interface with the phone or network telephony functionality initiated from the code. WTA functions can be stored (in an abbreviated subset) on the device itself to save expensive communication trips to the WTA server. The danger in this is that if the software on the device is tampered with, the permissions and regulatory actions normally performed by the WTA are left to the phone's security.

This possibility presents an interesting dilemma. Trust the WTA gateway, and store more functions on it (allowing it to control all telephony activity on a device), or trust the phone hardware and software manufacturers to implement permissions appropriately, and leave more WTA functions on the phone (affording less trust to a WTA server). There are no easy answers. Without any foundational security model, the severity of attacks against wireless devices will increase as these devices become more critical to users and businesses in storing and processing confidential information. Telephony functions will likely be an area of amateur attacks. Much like e-mail viruses, the types of attacks that target telephony functions will be directed at damaging information, usurping pricing models, or otherwise wreaking havoc on current structure. E-mail viruses do not (typically) exploit sensitive data or seek to steal or alter sensitive data. That class of attack falls elsewhere in our discussion of WAP security than exploiting WTA functionality.

WAP Security

After close inspection of the technical specifications for all aspects of WAP, paying special attention to the WTLS specifications, it becomes increasingly apparent that one major design flaw exists. There is a glaring lack of security design specifications in the WAP framework. The security built in to WAP systems is left entirely to architects and developers. WTLS provides an important piece of the puzzle, but in no way does it provide end-to-end security—in theory or in practice. Wired system architects are no strangers to insecure platforms. Smart wired system architects recognize that even if a platform is labeled or advertised as secure, it shouldn't be trusted—not if any information it touches holds value or is sensitive.

WAP has the same limitations as other wireless technologies. It is limited by size, space, speed, and cost. The requirements for building a secure system must be tailored when these factors come into play. As some Web application developers are tricked into a false (not to mention, dangerous) sense of security by employing SSL and encryption, so too can wireless developers fall victim to a similar fate. WTLS certainly adds a layer of protection to transmitted data in WAP systems. However, it does not provide any assurance against malicious content that runs on the device or for online application exploits of WAP servers. For this reason, it is necessary to focus the discussion of WAP security on the WAE layer, and specifically on WML scripts that run in the application layer of wireless devices. The scripting threat to WAP-enabled wireless devices is likely imminent. Malicious scripts can infect mobile devices just as they do devices plugged in to the wired Internet.

Many security features in WAP are heavily rooted in trust of entities out of your control. WAP gateways are trusted to decrypt and encrypt data, rendering it open to compromise from various methods of attack. A WAP gateway can be a simple NT server with the necessary applications running, sitting in an unlocked closet in an unlocked hallway of a national wireless service provider's regional office. There is no guarantee that the security proffered by the regional office is sufficient to protect data to the standard you require. Too many links in this chain are variable and unknown for you to assume that all of it can be trusted.

WTLS is employed so that the system is secure, end to end. Partial security is, in reality, insecurity. The security features inherent in the WAE place requirements on WML and WMLScript, as well as on WTA functionality, but their effectiveness is directly tied to the state of their implementation. In WTA functionality, either the device manufacturers or the WTA server must be trusted, both of which are typically out of a developer's control. WML and WMLScript are limited subsets of languages with known security problems. By stripping down already faulty languages, security paradigms for development must be altered. In their current state, WML and WMLScript have to be coded extremely securely to offer the appropriate level of security required in most corporate wireless systems and demanded by consumers who are paying bills, checking secure e-mail, or initiating stock trades via their mobile devices.

In too many places in the WAP architecture, the sole option for designing security is to trust an entity that is out of your control. The only viable solution is to develop security into applications so that your own resources are protected from system compromises and inadvertent or malicious attacks.


Chapter 4. Devices

Everything that can be invented has been invented.

—Charles H. Duell, commissioner, U.S. Office of Patents, 1899

Device security begins with one simple concept: Treat your device as you do your wallet. The single biggest security risk in using mobile or wireless devices is that it can be easily lost or stolen because of its small form-factor. Some devices have a locking feature that allows them to be secured by a simple PIN. This does not protect the data stored on the device but does prevent the person sitting next to you in a dark movie theater from accidentally making a call on your phone.

Devices are a challenging area of our investigation into wireless security. They are, by far, the most likely of all components in our research to evolve and change rapidly. The voluminous impending changes make this chapter difficult to structure. We have not yet progressed to a time when all wireless networks are standard and compatible (as wired networks are). We have 802.11x networks, Bluetooth on the horizon, and iMode in Asia, but none has proven its worth or market share across the globe. Devices are still varied and nonstandard. Phones, PDAs, and wireless-enabled laptops are three categories of devices. Within each category, you find myriad differences and nuances, making each device unique and making security planning for such a wide audience exponentially more difficult.

This chapter investigates a few PDAs and a phone. Because OSs are largely tied to vendors at this stage of wireless technology evolution, we define categories of PDAs or phones by their OS/vendor labels. Wireless-enabled laptops are not explored here because they do not represent the same limited-device platforms as the former categories. They do represent a significant portion of devices used to connect wirelessly to networks and the Internet, but their uniqueness lies in their connection methods, not in the devices themselves. PDAs and phones represent a distinct breed of devices.


Personal Digital Assistants

Personal Digital Assistants (PDAs) first appeared on the market in the form of electronic organizers. Organization remains their primary function; other features have been added as demand changes. The most basic organizers, often termed PIMs (Personal Information Managers), include a calendar, an address book, and a primitive notepad. PDAs serve as organizers almost without exception. The Franklin Day-Planners of old have been replaced with this new electronic way of managing personal information. Most PDAs also have the capability to synchronize with a PC, whether to upload or download information from a proprietary application for storage and backup purposes or to synchronize with popular PC organizers such as Microsoft Outlook or Lotus Organizer. This enables users to avoid the hassle of maintaining both paper and electronic versions of business or personal contacts, meetings, or appointments.

The ability to tote these PDAs anywhere you go makes them mobile, but not necessarily wireless. The ability to connect without docking with a PC makes a PDA wireless. The devices we cover in this chapter are wireless, whether inherently so or enabled via an add-on such as a wireless modem. More recently, PDA vendors are offering add-ons to bolster functionality. These additional components can play music, add memory, function as a modem, or add storage space.

Memory expansion is an attractive feature in many PDAs. Memory that is added to a mobile device is called flash memory. It can be programmed and erased repeatedly and consumes power only when accessed. Obviously, this is an important feature for devices with constrained battery power. Flash memory also retains its information after it is turned off. Memory upgrades are proportional to their size. Flash memory extensions the size of a postage stamp typically add 8MB of memory to a device, but larger format extensions can accommodate more than 64MB of memory. The catch is that, when adding 64MB of memory, the cost of the extension flash memory can sometimes exceed the cost of the PDA itself. See Table 4.1 for the sizes of various memory cards.

Table 4.1. Memory Card Sizes

Card

Size (mm3)

Springboard

23,085

PC card

14,552

CompactFlash

7,740

Average credit card

4,644

MemoryStick

3,010

SecureDigital

1,613

SmartMedia

1,265

MultiMediaCard

1,075

A PCMCIA card is an option when seeking to expand a PDA's functionality. PCMCIA cards, or PC cards for short, have long been industry-standard extensions for desktop systems. The physical hardware interface is not integrated into mobile devices as of yet because of the battery power required to supply the connector. To solve this problem, many devices feature sleds, an add-on that fastens to the PDA and allows PC card integration. PC cards are very taxing on batteries and are not seen as often in PDAs with smaller batteries. Sometimes PC cards exist as adapters for still other expansion cards, which are smaller. A PC card–to–Memory Stick adapter allows a Memory Stick to be inserted into a PC card. The Memory Stick can be inserted into a PC card in a laptop, for instance, and data can be transferred manually between the laptop and a PDA with a PC card adapter. Adapters are available for several additions, such as Secure Digital, SmartMedia, MultiMediaCard, and CompactFlash cards. For more information on PC cards, see http://www.pc-card.com . For more information on Memory Stick, see http://www.sony.com.hk/Electronics/pr_t/tec/memory .

One popular expansion module is Handspring's proprietary interface, Springboard. Boasting the largest physical capacity of the expansion cards, it also provides the highest data transfer rate. The data transfer rate is made possible by the attachment of I/O devices directly to the processor bus. Some Springboard modules support their own separate batteries to support functionality that requires more power. For more information on Springboard modules, see http://www.handspring.com/developers .

The CompactFlash card is supported across the board on most PDAs. It can be attached by insertion into a PC card adapter and provides additional memory to add-ons such as portable MP3 players or bar code scanners. CompactFlash cards also provide a platform on which additional functions can be built, such as serial ports, Ethernet cards, GPS devices, or modems. For more information on CompactFlash, see http://www.compactflash.org.

Secure Digital (SD) Memory Cards offer high storage capacity (32MB and 64MB currently and 128MB and 256MB scheduled for release), fast data transfer, and limited security. Their purpose is to store information downloaded from a desktop system and then transferred to a smaller device such as a PDA. For more information on SD Memory Cards, see http://www.sdcard.org.

Two other forms of expansion technologies are the MultiMediaCard, which acts as a storage medium for MP3 players, and SmartMedia (or Solid State Floppy Disk Card [SSFDC]), which acts as extra file storage space. Information about the MultiMediaCard can be found at http://www.mmca.org and about the SmartMedia card at http://www.ssfdc.or.jp/english.

Not all expansion interfaces are supported on all platforms. RIM's BlackBerry supports none of the expansions discussed here. High-end models of the EPOC platform support CompactFlash and MultiMediaCards. The Pocket PC offers limited integration with PC cards, CompactFlash, MultiMediaCards, and Secure Digital Memory Cards. Palm OS devices have some integration capabilities with all expansions mentioned except PC cards (although Springboard expansion modules can be used only on Handspring proprietary devices, which do use the Palm OS).


Palm OS Devices

The Palm OS allows users to browse the wireless Web and the actual Web only in what it calls Web clipping, a browsing technique that strips graphics and complex functionality out of Web pages, leaving bare text to be displayed on a mobile device. Applications developed for Palm OS devices have become available in full force. They range from games, to office automation tools, to music players, to reference tools. The biggest advantage for Palm is its name brand recognition. Unfortunately, its production of new and exciting products has slowed as of late. Where Palm is slowing, other vendors are picking up the pace.

Two types of applications can be run on a Palm OS device: Web clipping applications (WCA) and regular GUI applications. On top of either of these, a conduit is sometimes necessary. A conduit is a tool used to synchronize data between a desktop application and a Palm OS device. WCAs are sets of HTML pages compressed into a proprietary format called a Palm Query Application (PQA) and downloaded to a device. Users input information to the HTML forms in these pages, and the WCA sends the request to the Palm.net proxy server. The Palm.net proxy server translates it into an HTTP request that is then forwarded to a company's Web server. That server is responsible for processing the information and returning the appropriate page. The returned page is relayed to the proxy server, compressed, and downloaded to the device. We are not sure of the degree of trust that should be afforded this proxy server, but applications developed in any environment should be constructed so that a compromise of sensitive data would not occur should the Palm.net proxy server be compromised.

WCAs are not standalone applications on a Palm OS device. They run inside a Palm OS application called the Web Clipping Application Viewer. The viewer is automatically launched when a WCA is invoked, or clicked by the user.

GUI applications that run on Palm OS devices are single-threaded and event-driven. Only one application can run at any given time. The OS automatically closes one application when another is invoked. Palm OS applications are compiled into Palm Resource Files (PRC files) and then downloaded to the handheld. The same PRC can run on any device licensed to run the Palm OS. Some of the devices have individual characteristics to which you can specifically program.

A few manufacturers license the Palm OS software and build devices around it. Palm's own devices, most recently the Palm VIIx, have only slightly different features from other vendors' devices powered by the Palm OS. Handspring, for instance, uses the Palm OS on its devices but adds functionality to attract portions of the market share. The most recent version of the Handspring products, the Visor Edge, has a 33MHz Motorola Dragonball processor. The Dragonball is the only processor that works with the Palm OS. It has 8MHz RAM and features the Palm OS 3.5.2H (not the most recent OS). The battery life on Palm OS devices is measured in weeks and varies, based on the screen brightness or applications run.

Input on typical Palm OS devices is accepted through a touch screen interface with a pen (called a stylus) used to touch options on the screen. Users can enter text either by selecting letter images on a keyboard on the screen or by writing Palm's signature, Graffiti language. Graffiti represents keystrokes used to write letters. The device recognizes keystroke patterns and displays the corresponding letters, numbers, or characters on the screen.

Network connectivity in Palm devices is offered in several forms. Connection via IrDA is integrated into the device. Serial or USB connections are possible via a cable by docking in a cradle. Connections are possible via a PC card or CompactFlash for 56Kbps modems and via PC cards, CompactFlash, or cradles for Ethernet. Springboard modules can provide connections to a cellular wide area network.

The Palm OS is logically similar to that of a traditional PC. At its base you find the device hardware and third-party hardware that can be added. Just above is the hardware abstraction layer, a software layout of how the hardware works. On top of this are the kernel and system services. The system services are a group of managers that give Palm OS its basic functionality:

· Graffiti manager

· Resource manager

· Feature manager

· Event manager

· Serial manager

· Sound manager

· Modem manager

Above these managers and system services are the system and third-party libraries. The system libraries include important components such as TCP/IP and floating-point support; they also allow developers to extend functionality of the OS. The third-party libraries can be communications-related or language-specific, such as Java libraries. Atop the libraries sits the application toolbox, and at the very top sit the device applications, such as the address book, mail functions, and calendar, as well as any third-party applications added to the device.

Palm Security

The last version of the Palm OS does encrypt passwords, but the encryption algorithm used has proven easily breakable. There is also a backdoor for the passwords, which can be easily used to circumvent the limited security a password provides. The backdoor is intentionally provided so that application developers can debug code. However, anyone performing source-level or assembly-level debugging can access information such as an encoded form of the system password and all information stored in the system database and can install or delete applications. The debugger is activated by using a short Graffiti keystroke pattern and is easily utilized.

As mentioned, according to Palm documentation, Palm OS 4.0 provides mitigation for this security problem. It also includes support for color displays and other supposed security enhancements. During 2001, Palm, Inc., announced its intention to spin off its OS department. The effect this spin-off will have on Palm OSs in general should prove interesting.

Palm OS data transfers are not encrypted by default. Additional applications can be used to introduce this functionality. Although some bolster the security offered, none provide an entirely robust security solution.

Palm OS 4.0

The newest version of Palm's operating system offers more expansion capabilities for secondary storage and has new APIs from the old versions. Palm OS 4.0 applications are copied into main RAM during execution and are removed automatically when terminated. Palm OS 4.0 supports multiple expansion cards in one device and extends the synchronizing API to provide access to expansion file systems. The install tool that comes with the OS supports non-Palm file types, enabling users to view different media types, such as music or graphic and picture files. A password is required to view details on event alarms, and the device can be automatically locked after a specified period of inactivity.


Pocket PC Devices

What began as the Windows CE operating system quickly changed into the Microsoft Pocket PC OS after CE's unpopularity became glaringly apparent. Microsoft dropped the Windows CE label after version 3.0 and began marketing its device and operating system as the Pocket PC only. (Although some devices are called Pocket PCs, for the purposes of this section, the term Pocket PC will be used to designate the OS itself.) The Pocket PC can surf the actual Web and can stream Windows audio and video. Surprisingly, Palm has a bigger market share, even though it does not provide full Web browsing capability. Microsoft targets the business market, whereas Palm markets itself as a personal organizer. Where Palm boasts name brand recognition, these devices boast functionality. The battery life, however, on a Windows CE device is far shorter than that of a Palm OS device. The battery life is measured in hours and maybe days, versus Palm's weeks.

Compaq's iPaq PDA runs on the Microsoft Pocket PC OS and uses the Intel SA-1110 206MHz processor, much faster than the Handspring Edge processor. It has 16MB flash memory and 32MB SDRAM. It integrates seamlessly with PC cards and CompactFlash and can run slimmed-down versions of Microsoft's Office products, Pocket Excel or Pocket Word. One nice feature of this OS is that it supports a variety of processors, unlike the Palm OS. Processor-specific information is contained in a few spaces in the Pocket PC OS but is assignable after a processor is chosen for a given device that will use this Microsoft Pocket PC OS.

Pocket PC supports both 1K and 4K page sizes so that it can be used on processors that support either size. Applications developed for use in a Pocket PC OS must be compiled in a processor-specific compiler. If an application is designed for use with more than one processor, it must be compiled on each compiler specific to a certain processor or family of processors. The OS supports 32 concurrent processes. Communication among processes is facilitated through Windows messaging, similar to how it works in other Windows OSs.

A Pocket PC system supports RAM, ROM, and flash memory. RAM is used to provide buffers for application data and to run applications. The OS provides battery-backed RAM, which gives the devices their instant on feature. ROM is used to hold programs. It has persistent contents and can be likened to a file system or disk storage space in a traditional PC. ROM contains the files that make up the OS. To prevent inadvertent overwrites of the OS-critical files, physically inserting a new ROM chip is necessary to upgrade the operating system. The alternative memory option is flash memory. It can be upgraded, but the OS's entire image must be set in, byte by byte.

The GWES (Graphics, Windowing, and Events Subsystem) provides services for the device. It includes power management, window and dialog management, user input services, and the graphics interface. The Graphical Device Interface (GDI) helps render text and graphics. GDI processes can be set in place to create windows and dialogs and interact with the user. Standard functions for each of these are available. The input support in GWES allows the use of various input mechanisms, a keyboard, a touch pad, or even a thumbwheel-type option.

The option to induce power management is an optional module. Most devices that feature the Pocket PC OS require power management, however, because they run applications that are very taxing on the battery. The power management of an extension module may be distinct from that of the device itself. There are four possible states of power:

1. No power. Only before the first configuration.

2. On. Full power.

3. Idle. On but inactive.

4. Suspend. When turned off, minimal power, but retains settings and programs. Power is suspended to peripherals and the CPU.

5. Critical off. Low battery causes cutting off power to the CPU and peripherals until recharged.

The Pocket PC file system allows access to data stored in all three types of memory, as well as extension devices as files or folders. The file system is based on file allocation tables (FAT). It works with extension storage cards that can be partitioned into sections named volumes. The volumes are accessible from the CE root directory. The Registry is part of this OS's file system as well. It is used by the OS and its modules, device drivers, and applications. Configuration information is typically stored in the registry and accessed upon initiation of an application. That same configuration information is also stored back to the registry upon termination of the application.

Network connectivity is possible in various ways with these devices, as with Palm OS devices. IrDA connectivity is integrated into devices, and serial or USB connections are possible with a cable or by docking in a cradle. PC cards and CompactFlash enable Pocket PCs to connect via 56Kbps modems or Ethernet, not via a cradle, as in Palm OSs. Whereas Palms cannot connect to wireless LANs, Pocket PCs can, with the use of a PC card expansion. Also, using a PC card, CompactFlash, or an IrDA link to a cell phone, Pocket PCs can connect to cellular networks.


BlackBerry (RIM 950 and 957)

Patented by Research in Motion Ltd. (RIM), a Canadian company, the BlackBerry device comes in two current models: the RIM 950 and the RIM 957. The 950 is approximately the size of a pager, with a small text screen. The 957 is about palm-size, and its difference from the 950 is simply a larger screen. Both devices have 32-bit Intel 386 microprocessors. The 950 comes with either 2Mb or 4Mb of flash memory, and the 957 comes with 5Mb. Flash memory preserves battery life and retains all information if the battery dies or is removed.

The BlackBerry solution is a device predominantly used for mobile e-mail access. It does not provide the extra functionality that other PDAs do (such as browsing the Web or reading files) but does what it does very well. Extra functionality can be added to a BlackBerry device by using its SDK and developing applications. BlackBerry added support for Java 2 Micro Edition in late 2000. Some applications, such as mini-browsers, are publicly available for use on BlackBerry devices. Following are three popular browsers available that were developed after-market:

· GoAmerica (HTML, WAP). www.goamerica.net/html/developers

· Neomar (WAP). www.neomar.com/developers/index.html

· Novarra (HTML, JavaScript, WAP). www.novarra.com

BlackBerry uses a push architecture instead of the traditional pull architecture in most other mobile devices. Devices using a pull architecture periodically connect to an e-mail server to check for messages. In BlackBerry's push model, new e-mails are connected to the user, and the user is notified that she has new mail. A copy of e-mails residing on corporate servers or a desktop PC is sent to the device. BlackBerry currently works out-of-the-box only with Microsoft Exchange and Lotus Notes. It began its implementations with Microsoft Exchange and added integration support for Lotus Notes in January 2001.

To save memory and battery life, only the first 2K of an e-mail message are delivered to the device. Users can choose to receive the rest of the message if they want to, although most e-mail messages are less than 2K. Attachments are not delivered to the device, either. They remain on the corporate mail server or in the user's e-mail account on a PC. If a message arrives with an attachment, however, and the user chooses to forward it to another person, the attachment is forwarded along with the message, even though the user never viewed it on her BlackBerry.

The BlackBerry Enterprise Server is available at a corporate level. This enables messages to be forwarded at the server—instead of the desktop level. It also affords mail administrators the ability to manage and control batch and security policies and includes support for Simple Network Management Protocol (SNMP).

Input on a BlackBerry is very different from input on other PDAs. Instead of a pen and touch screen, the devices have a QWERTY keyboard for text input and a thumbwheel for scrolling through menus and selecting items. Although the keyboard takes getting used to because of its small size, when a user becomes accustomed to it, typing e-mails is natural and easy.

The AutoText feature makes input much easier. When enabled, AutoText allows users to specify shortcuts for commonly used words or keystroke patterns. For example, when composing an e-mail, if you type a period followed by two spaces, the next letter is automatically capitalized. Certain contractions are also commonly used AutoTexts, for instance, if a user types dont, the device automatically adds an apostrophe, changing it to don't.

Network connectivity is possible via fewer total means than Pocket PCs or Palm OS devices, but more network connectivity possibilities are integrated into BlackBerry devices. IrDA, 56Kbps modems, and connections to a cellular, specifically Motient, network are integrated in the BlackBerry device. It is possible to connect to a desktop via a serial connection and docking cradle. Support for USB and Ethernet and connections to wireless LANs are not possible with the current devices.

The BlackBerry OS architecture is a closed architecture. It is difficult to gain specific information other than those API descriptions provided in the SDK about the architecture itself. To this end, our discussion of a BlackBerry device's architecture is limited. There are obviously advantages and disadvantages to having a closed architecture. It is challenging to learn about the device, to find its security weaknesses and protect against those weaknesses. On the flip side, however, the security weaknesses are not easy to discover and, theoretically, less likely to be exploited. This last reason does not afford much comfort, though. We must operate as though the device deserves limited trust but is not wholly trusted.

BlackBerry APIs

Information pertaining to the hardware in BlackBerry devices can be organized in several ways. It is best to work backwards to the hardware from the APIs to see these categories. The three main categories of APIs are

1. Database API

2. Radio API

3. User Interface (UI) Engine API

Table 4.2. Commonly Used BlackBerry APIs

Database

Address Book

Radio

Message

View

Compose

UI Engine

AutoText

Options

Ribbon

In each category there are important main functions to know. The most important API in the Database group is that which allows operation of the Address Book. The database and file system is relatively sophisticated. The database manager allows adding, deleting, and navigating through database records. All the data is stored in flash ROM, which we define as nonvolatile, permanent memory, and data is retained even when the battery is removed or the device is powered off. Flash is quick to read but slow to write to.

All applications can use the same Address Book. The Address Book integrates with the Message API. Table 4.2 shows commonly used BlackBerry APIs. The Radio API group houses the Message API. The Message API has two main capabilities: viewing and composing a message. Messages are created the same way BlackBerry creates e-mail. The Compose API talks to the UI engine, which houses the third group. The UI engine includes the AutoText feature and the Options and Ribbon features. The Options API allows applications to use the same settings, such as notification type (beep, vibrate), date, time, and auto on/off. The UI Engine API contains function calls that allow applications to create custom screens, menus, dialog boxes, status boxes, and fields. The UI can return a message or any event based on user input or action.

As many as 31 applications can run simultaneously on a BlackBerry, with just one in the foreground at any given time. Each of the other applications remains silent until a trigger event wakes it and delivers it to the foreground. Trigger events can be activity on the serial port, a user pressing a key, a timer counting down to 0, a data packet received, or movement of the thumbwheel by the user. Applications act on the events and then return to the background.

The hardware in BlackBerry's architecture fits with the APIs as described here. The Database APIs work with the Files, Memory, and Scheduling components. The Radio APIs work with the actual radio and serial port; the UI Engine works with the Screen, Keypad, and Thumbwheel.

BlackBerry Security

Although receiving personal or internal corporate data via the Internet does not introduce a hole into a corporate firewall, it does introduce a point of attack. BlackBerry devices receive e-mail sent over the Internet, which is publicly accessible. To mitigate this problem, BlackBerry encrypts its communication. The keys for encrypting and decrypting are stored only on the device and at the desktop. Protection is also afforded to the BlackBerry redirector, which forwards incoming mail to the device. A malicious person simulating RIM device commands to the redirector will be unsuccessful without knowledge of the shared key. The redirector responds only to commands encrypted to the key it shares with the device. The encryption method used in encrypting BlackBerry e-mails is triple-DES encryption. This encryption standard is considered the most widely accepted of industry-approved encryption algorithms, provided that the keys are created appropriately (see Chapter 6 , "Cryptography," for a discussion of triple-DES). When keys are generated for encryption algorithms, they must gather a certain amount of randomness (explained in detail in Chapter 6 ).

BlackBerry gathers randomness in creating its private and shared keys by asking the user to move the mouse. This is a common method for generating randomness. It cannot be assumed to be exactly enough but represents effort on RIM's part to collect randomness from a human-generated source.

Another significant component in an encryption process is the distribution of the keys. We have noted that the keys are stored only on the device and on the desktop, but the process for getting the keys to the device is important. If the keys are sent over a wireless link or an Internet connection, they can be captured. BlackBerry transfers keys only while the device is docked in its cradle and directly attached to the desktop via a serial cable. This is an acceptable method for transferring keys. Although BlackBerry's method is not sufficient for protecting matters of national security, this method does speak to BlackBerry's commitment to develop appropriate security into its devices.

The device can be password-protected if this feature is activated. When established, the user can easily lock the handheld to protect the device from unwanted use. This password also prevents access via the serial port and docking cradle. A timeout can be set on the device so that after a specified amount of inactivity in an unlocked state, the device locks itself, requiring the password for unlocking.

An interesting feature BlackBerry includes is that if an incorrect password is entered ten times, the device's memory is automatically erased, rendering it unusable. The applications can be reloaded at the desktop, but the data stored on the device is erased. BlackBerry documentation notes that the password is obfuscated on the device so that if someone were to download the contents of memory from the device, the password would be unattainable. We are unable to verify that this is the case. When a corporation uses the BlackBerry Enterprise Server administrators can require passwords to be used on devices and can specify a minimum length for all users.

The piece of the puzzle here that is most unrelated to BlackBerry devices themselves but can, perhaps, open the most doors to attack is the user's desktop. Leaving the desktop unattended, unlocked, or on without proper physical security can expose the device and its contents to compromise. This does not supersede prevention that should occur at a desktop level in general. It just follows that if a desktop is not properly secure, this device cannot be assumed secure as well.

We do not investigate the BlackBerry Enterprise Server here, but you should note that it requires integration with a corporate firewall and introduces administrative security issues that should be examined before implementation. For more information, see http://www.blackberry.net/international/uk/solutions/pdfs/BlackBerry_Enterprise_Server_for_Exchange_GPRS_Technical_White_Paper.pdf.

Each type of device is unique. Knowledge of one device's intricacies does not translate into working knowledge of another's. This chapter presents a range of considerations. It is imperative that you gather specific information about devices used in your system. Security measures or functionality present in one may not be present in others. Verifying all components of a device is up to the system architects and application developers because no one can predict those that will have security implications and those that will not.


Chapter 5. Languages

The secret of eternal youth is arrested development.

—Alice Roosevelt Longworth (1884–1980)

By now you should have noticed a theme—there is more than meets the eye when considering wireless systems. So, too, is the case with wireless languages. Wired languages and wireless languages do not differ in many ways, but in their differences lies dangerous ground. If developers are not aware of the differences, applications can be wide open to attack. Wireless application languages are specially designed to accommodate smaller display screens, slower networks, and devices with less memory. Typically, intensive processes are run on servers, rarely on devices themselves. Although this applies more to applications that will be run on PDAs or cell phones instead of wireless laptops, it is the focus of this chapter. The languages we cover are Java 2 Micro Edition (J2ME), Wireless Markup Language (WML) , and its partner script, WMLScript . (Both WML and WMLScript are used in WAP systems.)

Now, if you are a project manager or anyone whose job function is at a higher level technically than a developer, this chapter may seem irrelevant for your security planning purposes. The devil is in the details here, and someone on a development team has to be responsible for expertise in wireless languages. This is a good chapter to refer a colleague and developer to—you can combine your recently acquired expertise in security principles as they apply to wireless systems with that developer's knowledge of wireless programming.

This chapter does not teach the languages to the extent that you can become proficient, or even to the extent that you can use it as a primary resource in learning about the languages. This chapter is included for completeness. It is our firm belief that understanding the ramifications of the programming language you choose for development is an important part in developing a holistic security solution for a given project or environment. To this end, we describe the languages in their most basic forms, discuss notable details, and provide insight into their security features and drawbacks. A background in programming languages such as HTML, Java, C, or C++ is necessary to achieve competency in the languages discussed here.

J2ME, WML, and WMLScript have several things in common. They are all subsets (whether or not directly derived) of traditional programming and Internet languages. J2ME is a subset of Java 2, WML is based on both HTML and XML, and WMLScript is based on JavaScript's earliest version, ECMAScript. They differ in their scope, functionality, and common uses. First, we will take a look at WML.


Wireless Application Protocol (WAP)

As you learned in Chapter 3, "Technologies," WAP specifications define a protocol stack similar to the Internet protocol stack. Each layer of the WAP protocol stack (Application, Session, Transaction, Security, Transport, and Network) represents an area where vulnerabilities can exist. The Wireless Application Environment (WAE), residing at the top of the WAP protocol stack, is the area of the WAP protocol stack on which we focus the bulk of our discussion here (see Table 5.1). Application issues are of interest for a variety of reasons. Although noteworthy security concerns are associated with all facets of WAP, the issues implicit in the lower layers of the protocol stack can be attended to similarly to wired Internet issues. Because those issues lower on the protocol stack can be mitigated, as WAP evolves, the Application layer becomes the most likely breeding ground for a new generation of attacks.

Faulty programming in the application environment and on the client can lead to serious problems in the wireless world, just as it can with any existing Web programming. In general, WAP developers should avoid translating existing Web applications to wireless ones by attempting modifications to the original code. Taking shortcuts can lead to vulnerable and poorly designed applications, at least where their usability is concerned.

Table 5.1. The WAP Protocol Stack

Functionality

Internet

WAP

Application

HTML

JavaScript

Wireless Application Environment (WAE)

WML, WMLScript

Session

HTTP

Wireless Session Protocol (WSP)

Transaction

HTTP

Wireless Transaction Protocol (WTP)

Security

TLS-SSL

Wireless Transport Layer Security (WTLS)

Transport

TCP

UDP

Wireless Datagram Protocol (WDP)

User Datagram Protocol (UDP)

Network

IP

Bearers: GSM, SMS, USSD, GPRS, CSD, CDPD, and the like

The WAE houses several services and functions to interact with its user agents: Wireless Markup Language (WML) and its partner script, WMLScript—based on HTML and JavaScript, respectively. WMLScript enhances WML's standard browsing and presentation capabilities by providing client-side scripting functionality to WML. It supports advanced user interaction, validity checks for user input, and local messaging (error messages, alerts, and the like) and provides a mechanism to access the facilities resident on the client. It is designed for use on a WAP-enabled device, specifically on thin clients with low bandwidth communications capabilities.

WML was created to facilitate displaying Web pages on wireless devices with small display screens. If you recall the discussion of WAP in Chapter 3, you will remember that WML is analogous to a watered-down translation of an HTML page. In addition to small display screens, however, WML accounts for the fact that input to these devices is difficult and varied, memory is not available in excess, and CPU cycles are limited (for a discussion on how these limitations affect the implementation of cryptographic security solutions, see Chapter 6, "Cryptography").

WAP Browsers

More and more pages on the wireless Web are being written in WML to avoid having to translate to or from HTML. WML pages are not to be thought of as a substitute for standard Web sites. They provide only a limited subset of information and graphics to wireless device browsers. To view a WML page, a device must have a browser, an application used to interpret and render the WML code on a display. In the wired world, browsers are required to interpret HTML; some popular browsers are Netscape Navigator, Internet Explorer, and Opera. Several types of browsers, produced by various companies, can render WML. Each phone manufacturer decides the type of browser to install. Each PDA manufacturer decides either to install a given browser or to offer it as an add-on. As the mechanisms by which users update software on these devices become easier to use and more prevalent, the capability to upgrade these browsers becomes more commonplace.

To understand certain risks associated with viewing WML pages on a WML browser, we must first visit the risks associated with HTML browsers. In the case of HTML browsers, vendors often release security patches or updates to existing versions and, from time to time, full-blown new versions. Because each version of a browser is in use for some time, attackers take aim at holes inadvertently left by vendor programmers. By exploiting these holes, attackers gain sensitive information from users' systems. Sometimes the holes are so unfortunately placed and the attacks crafted in such a way that an attacker can take full control of a user's machine. Because HTML browsers can be customized when installed on a machine, it is possible to disable some of the functionality (that is, scripting or Java) that could enable exploits to come to fruition. By turning off scripting or Java, users can protect themselves from certain attacks, both known and unknown.

In a WML browser, these options are not as easily configurable by the end user— yet. As time progresses, however, this will become status quo. Tailoring WML browsers to meet the security needs of business and personal users will become possible.

Staying consistent with one theme of this book, with all security features there are functionality drawbacks. In disabling features that could leave you open to an attack, functionality loss is suffered. In a corporate environment, a blanket policy requiring that all users disable Java and scripting could force functionality loss that is counter to business productivity. If staff who follow this policy cannot access critical applications or retrieve necessary information, this lack of ability is a problem. The appropriate course of action in determining which functionality to disable and which to leave vulnerable is to weigh all components of the issue, as discussed in Chapter 2, "Security Principles," and Chapter 11, "Analyze Mitigations and Protections." The answer to this question is found in examining the information to be protected, the risk if it is exploited, and numerous other factors.

If we could infallibly predict the occurrence of an attack, we could patent a Predicting Attacks formula and retire comfortably tomorrow. The factors that come into play in assessing the likelihood of an attack's causing damage are dynamic and often unpredictable. The uncertainty of these factors make calculating the likelihood of damage with any degree of certainty virtually impossible. Not enough variables can be isolated to solve an equation and come to a meaningful conclusion. Chapter 6 discusses in detail the process necessary to determine an appropriate course of action, but it cannot begin to calculate the likelihood of an attack in any specific percentage.

Obviously, using a browser for general home purposes is worth the risk of an attack. The information that can be gained, the applications that can be executed, and the convenience that is drawn from using an HTML browser to browse the Internet are usually viewed as significant enough to warrant risking an attack. If, however, you believe that the potential exists for anyone to attempt to compromise your computer through a browser hole, you may feel differently. By being aware of attacks, protecting your data, and keeping your browser up-to-date, you minimize this risk.

What is the risk in using WML browsers? It is much the same as in using HTML browsers. When attackers can exploit holes left by insecure code and architecture of a browser, wireless devices become open to attacks ranging from information leakage to complete control by a malicious party. Keeping the most current version of a browser is essential. Right now, the set of information available via these browsers is smaller than that which is available via HTML browsers, by its very nature. This is changing as quickly as the rest of technology.

Another significant risk in using WML, from a security perspective, is in the translation that occurs between HTML and WML. It is assumed that translation servers are trusted, but this assumption can lead to a false sense of security. To alleviate just one problem in a WAP system, clients could be required to accept only WML pages, avoiding the need to pass through a translation server in addition to an already risky WAP gateway.

Wireless Markup Language (WML)

Although WML is similar to HTML (closest to version 4.0) and XML, programming in it requires the use of different tags and structures. WML adopts its application model from HDML (Handheld Device Markup Language). It does require the XML-specified Document Type Definition (DTD) at the beginning of its code, including the official public identification of the Standard Generalized Markup Language (SGML) and the syntax definition for the document.

WML is, however, organized in a much different fashion. Converting a document from XML or HTML to WML is nontrivial. WML is ordered in decks of cards instead of groups of pages. When a user on a PC connected to the Internet types in a URL to request a Web page, the user's browser contacts the host server for the requested page and renders it via the browser on the user's PC. When a WAP-enabled cell phone user, for example, requests a Web page, the browser requests that page, termed a card, and returns not only the requested card but a set of cards, called a deck, or a group of cards associated with that single URL. The requested card is returned as the top card in the deck and is rendered by the cell phone browser for the user to view.

Because an entire PC-sized Web page cannot be rendered, it must be broken intelligently into smaller subparts (the cards) and delivered as a package (the deck) that can define user interactions and directions in displaying its information. The tag, <wml>...</wml> defines a deck and holds a group of cards together. The metaphor of decks and cards describes how the data is displayed when rendered in a browser, not how it is stored. A deck can be one file, beginning and ending with the <wml>...</wml> tags and containing <card>...</card> tags throughout to define the segmenting of the display on a wireless browser. The following is an example of a simple Hello World page in WML:

<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<!–Hello World in WML -->
<wml>
       <card id="Card1" title="WML example">
              <p>Hello World</p>
       </card>
</wml>

Cards are named with an id in the <card>...</card> field so that they can be identified easily inside a deck. The reason cards are sent in decks and not individually is that the most costly parts of WAP data exchange are the communication round-trips. Anything that can be done to minimize the number of times a communication round-trip must be made decreases the cost of a system. Each card displays hyperlinks just as HTML pages do. The tricky part for programmers is to organize the decks as intuitively as possible. When calling up a page such as www.yahoo.com, for instance, the developer might guess that the user will want to view a subdirectory listing of a certain category, say, Local News, for the user's zip code. The developer would include with the initial deck some cards associated with top news stories in anticipation that a user will need to access those pages next. Alternatively, the developer might guess that the user will, instead, be searching for another lower-level directory listing of News so that she can choose among Associated Press news, Reuters news, or other newswire services, and the developer would send different cards in the initial deck. This deck might contain a card for the Associated Press and a card for each news agency for the user to select.

The two methods of sending cards to a deck—estimated target hits down a vertical clickstream (that is, News, Local, Zip Code, Cards for each story) or a horizontal clickstream (that is, News, Cards for AP, Reuters, and so on)—are useful in different situations. WML specifications make no design recommendations for organizing cards and decks. Making these judgments is up to developers. Adept understanding of user behavior and choices leads to cheaper applications. Developers who correctly anticipate the cards a user will likely need to access, based on links clicked from a previous card, will have more user-friendly and thus successful applications. This is not as much of a concern on the Internet as browsed by wired PCs. Except in the case of old billing models and slower speed connections, the time required to render a page on a wired PC is negligible and does not affect a Web site's organization in the same way.

When a user clicks a link, one of two actions can ensue. If developers and designers correctly anticipated the clickstream choice, the user clicks a link that refers to a card in the same deck. The initial card is moved to the rest of the deck, and the newly requested card is rendered at the top of the deck in the client's browser for the user to see. If developers or designers incorrectly guessed which cards the user will request next, the initial deck is discarded from memory, and a second deck is sent, with the requested card on top.

There are, of course, self-contained decks, those that perform a limited function and do not contain links to cards outside the deck. Browsing is much less taxing on a system and faster for users when this is the case.

Unlike HTML, WML is translated into binary code at the WAP gateway before being sent to the WAP device. To fit the narrow bandwidth typical in wireless communication, both WML and WMLScript code are compiled into bytecode on the server and then sent to the user agent. The bytecode is a binary representation of the text-based WML and WMLScript code. It is structured very similarly to binary executable files. The advantage of a bytecode file over a binary executable file is that it is machine-independent. It is compiled once and run on any machine capable of running a WMLScript interpreter.

WML browsers, WMLScript libraries, and a WMLScript interpreter are physically placed on the mobile client by its manufacturer. Because WMLScript compilation units are compiled into the WMLScript bytecode before they can be run on a WAP client, each client has a WMLScript interpreter that interprets the bytecode it receives.

The card/deck structure brings no direct security concerns to the table. What the structure does do, however, is introduce a new variable into the equation that inherently requires more time and effort on a developer's part. As with HTML, WML is a formatting language. Rendering the pages is up to the browser, not the language that describes how data will be displayed. In the browser is where you find security concerns (discussed later).

Protecting Deck Access Using the access Element

WML provides a basic method of protecting access to a deck. The access element allows a programmer to designate those entities that have access to a given deck. A browser attempting to access a card from a deck outside its current one enforces access control by this element. The browser must evaluate the permissions defined by the new deck to determine whether the existing deck can access its contents. The security concern brought about by this function is that it does not protect the data within the deck. The browser has access to the data while checking permissions. If the browser is trusted, this is not a problem. However, because the user has little control over the browser, a rogue browser could be created that would compromise the integrity of the data.

The method an access element uses to specify permissions is based on the domain and path of the originating request. The domain and path attributes are used to set these rules. See Singhal (2001) for examples of these. If neither a domain nor path is specified, the default access parameter is that only cards from the domain of the deck itself are allowed access to it (as long as the access element is invoked). If the access element is omitted, the deck is considered accessible from any source. Domains should be specified at the broadest level to which access is permitted. If you want to restrict a deck to be accessible by virginia.usa.com, maine.usa.com, and washington.dc.usa.com, you need to specify

<access domain="usa.com"/>

Be aware that this also grants access to any originating domain that concludes with usa.com. If you want to restrict the deck further to include vienna.virginia.usa.com and oakton.virginia.usa.com but to exclude portland.maine.usa.com, you need to specify

<access domain="virginia.usa.com"/>

This excludes anytown.anyotherstate.usa.com because the allowable domains must be an exact match.

Protecting Deck Access Using the path Element

The second way of limiting access is by specifying a path. The path attribute designates access to decks in given paths on the application server. The path is derived from the prefix of the requesting or originating card. The beginning of this path must be an exact match as well. If you have, for example, a WML document residing at http://usa.com/states/list.wml and the following specification is set, any document that falls below the /states tree and is also below the usa.com domain can access the deck:

<access path="/states"/>
Coding with Due Diligence

Recall the Chapter 2 discussion of security concepts. Access control is not security.3 Much more is involved in protecting data, resources, systems, and applications. Responsible coding is a large part of developing secure applications. This book does not endeavor to discuss every element of WML or J2ME (or any other wireless programming language, for that matter) with respect to security considerations. Instead, we recommend that coders know the languages inside out, be aware of the common pitfalls, and understand appropriate methods for building secure applications. Although we explain the architectural considerations necessary for making decisions about designing secure wireless applications, due diligence dictates that coding be taken seriously. The importance of investing in coders with appropriate security background cannot be stressed enough. We recommend the following resources to bolster the actual coding of secure wireless applications.

Wireless Application Protocol Specifications

The specifications for WML are available at http://www.wapforum.org/what/technical.htm. Although they are a good resource for learning the building blocks necessary to code in WML, they do not provide solid security architectural design recommendations. A little knowledge can be dangerous. An understanding of the specifications outlined by the WAP forum is essential but not nearly enough to make you adept at writing secure code.

Device-Specific Books

After you decide that you need to code to a certain device, you should certainly learn more about the security design recommendations for that device. Books we find helpful include

· Palm Programming: The Developer's Guide by Neil Rhodes and Julie McKeehan

· GPRS and 3G Wireless Applications: The Ultimate Guide to Maximizing Mobile Internet Technologies by Christoffer Andersson

· The Wireless Application Protocol: Writing Applications for the Mobile Internet by Sandeep Singhal et al.

Other helpful books are appearing on shelves daily. At the risk of repeating a lesson surely taught in programming classes, understanding the relationship between the language and the device on which it will be used is crucial. (Although this is suggested here in the context of WML programming, examining these resources is important, no matter which language is chosen for development.)

General Software Security Books

After you master the mechanics of coding in a new environment, you must incorporate certain security design paradigms necessary to building applications in general, whether or not they are for the wireless world. When reading a book on general software, you must bear in mind the limitations the wireless realm brings to the table. As recommended earlier, Building Secure Software by John Viega and Gary McGraw is a valuable resource in this domain. It focuses on the security aspect critical to many applications. (Regarding device-specific books, note that this is also applicable to J2ME-developed applications or applications in any other wireless language.)

WML by itself affords limited function. It describes formatting, contains text, provides links for navigation, and contains commands that can be used to run scripts. It does not allow programmers to perform all the functionality necessary to develop robust applications. For this reason, WML Script was introduced.

WMLScript

WMLScript is based on ECMAScript and JavaScript. According to its specifications, WMLScript uses similar syntax and constructs and provides semantically equivalent functions. The theory behind WMLScript is different from that supporting JavaScript. It is designed for capability-limited devices.

WMLScript gives WML added functionality just as JavaScript adds to Java. With WMLScript, WML decks can perform processing they would otherwise rely on a server to perform. WMLScript enhances WML by providing browsing and presentation functionality that betters WML pages from a usability standpoint. The following is a list of functions that WMLScript adds to WML, according to its specifications:

· Checks the validity of user input

· Provides access to the device's facilities (for example, on a phone, allows the programmer to make phone calls, send messages, add phone numbers to the address book, access the SIM card, and so on)

· Generates messages and dialogs locally, thus reducing the need for expensive round-trips to show alerts, error messages, confirmations, and the like

· Allows extensions to the device software and the capability to configure a device after it has been deployed

· Provides more advanced user interface functionality

· Reduces the amount of bandwidth needed to send data between the server and the client

WMLScript libraries add significant functionality and are present in devices designed to interpret and render WML and WMLScript. The default libraries, however, can and should be expanded on to include custom libraries that enable applications to access the features of a device that make it unique. The feature that distinguishes a Handspring Visor from a Palm Vx cannot be easily invoked with generic libraries. Coders with a certain amount of prowess can dispatch specific libraries to make the most of their devices' special properties. If you are developing applications for cell phones, perhaps tailored WMLScript libraries can define specifics related to call control, synchronization with a PDA, or access to various storage areas in the device.

WMLScript is similar in syntax to C++ or Java. It is case-sensitive, and statements are terminated with a semicolon. As in C++, a double slash indicates a line comment, and a statement beginning with /* and ending with */ denotes a block comment. WMLScript is a procedural language that is extendable by adding the customized libraries just mentioned. It is not object-oriented, nor does it have an object model. Instead of ECMAScript's 64-bit floating-point math, WMLScript features 32-bit integer math with optional floating-point support. Unlike WML, it does not support global variables and does not have appropriate error handling. The error-handling mechanism is based only on the (invalid) error value. The invalid data type is distinct from strings, integers, and so on, and carries with it its own rules. In most cases, the presence of invalid in an expression causes the result of an expression to be invalid.

WMLScript supports standard libraries of WMLScript procedures installed on the clients themselves. It does not support certain more advanced features of JavaScript that require more computational or bandwidth capabilities. WMLScript can call remote scripts via URLs but cannot invoke libraries physically located on the client besides those in its own libraries. WMLScript compilation units, resources, and functions are accessed by using URLs because they are not embedded in WML code. A user agent can make a call to an external WMLScript function by providing the compilation unit's URL and the function name and parameters as the fragment anchor. The requested URL must be escaped according to the URL escaping rules because no compile-time automatic escaping, URL syntax, or URL validity checking is performed.

Telephony Functions

One of WMLScript's main additions to WML is that it allows applications to access client functions. Of particular interest are those mechanisms designed to interact with the client's telephony-related functions. These mechanisms, called Wireless Telephony Applications (WTA), include features that need to be protected from unwanted use or access in security considerations in applications and networks. The WTA functions are

· Accepts or initiates a call

· Sends or receives text messages

· Adds, searches, or removes phonebook entries

· Examines call logs

· Sends Dual Tone Multi-Frequency (DTMF) tones during an active call

· Presses keys on a keypad during a call

WMLScript invokes the WTA Interface (WTAI) to manipulate telephony functions of the phone. WTAI functions are included in WMLScript libraries and are called as WMLScript functions. These types of functions have parallels in the wired Internet world but invite different exploits in the wireless world. A whole host of new attacks can be designed to use these seemingly benign functions in a malicious way. WTAI functions that access phonebook entries provide WMLScript access to storage areas in the phone. Whether this simple access to an indexed array such as the phonebook can be extrapolated into misuse has to be investigated. Certain exploits can be constructed by manipulations that are not intended but also not prevented.

For a good description of the literals, variables, type conversions, operators, identifiers, statements, and functions used in WMLScript, see Chapter 9, "Scripting and Using WMLScript and WTAI," of The Wireless Application Protocol: Writing Applications for the Mobile Internet by Sandeep Singhal et al. These are worth investigating but do not differ enough from other languages to warrant significant concern on our part for their wireless implications.

Risks and Exploitation

Current WMLScript applications are predominantly benign, accessing WTAI functions for legitimate purposes such as placing a call from a link on a WML page, directing incoming calls to voice mail upon a user's request, or forwarding an incoming call to a different phone number. These benign uses, however, come dangerously close to malicious activity.

In the wired Internet world, different browsers behave differently. Wireless phone browsers are not an exception. Discrepancies run rampant among browsers, phone manufacturers, and applications alike. The major WAP-enabled phone manufacturers such as Nokia, Ericsson, and Motorola provide SDKs that specify differences in countless implementations. As in the wired Internet arena, time to market for WAP applications is decreasing rapidly. While developers race to produce new applications, the myriad inconsistencies require layers of minute coding differences that can be easily dismissed, leading to serious security flaws.

This complicates the problem originally facing developers, that there are many functions on which malicious users can attempt to get their hands. Placing unauthorized long-distance calls and broadcasting or erasing phonebook entries are only two of the problems that must be prevented with safe coding practices.

For example, the intended implementation of the WTAI function WTAVoiceCall. setup that makes a call is to display the phone number before the call is made. If the WAP browser being used does not prompt the user before placing the call, the call is automatically activated. In Japan, a prank was played on phone users who pressed a number in response to a voice mail message that automatically dialed the Japanese police emergency number without the callers' knowledge. Japan uses imode technology, which is different from WAP but represents an initial exploitation of a native capability.

The specifics of the browsers for which your team develops must be investigated. If a browser does not protect against certain potentially malicious activities, prevention mechanisms must be built in to the applications.

In the security model, some risks will be avoided. Calling functions that are not external, passing illegal parameters, and accessing a WMLScript called from an unauthorized domain and path will be prohibited. DNS spoofing, however, can circumvent the last of those three, possibly sending unwanted information to an unknown location. A smart WAP programmer recognizes that to be completely safe, certain additional safeguards should be taken in WMLScript usage—not only in the use of WTAI functions but also with respect to all areas of the client—so that even trusted servers and gateways cannot be the scene of an unwelcome attack.

The restrictions on WMLScript span beyond the realm of WTAI functions. WMLScript has few limitations and access control parameters. It is up to developers, service providers, and gateway hosts to control which parts of the client are protected and under what conditions they can be accessed. WMLScript libraries have limited functions and have methods for controlling their use. The problem is that the controls are not necesssitated; they are merely suggested.

Securing information on a phone is possible, but loose coding practices open doors to many forms of attacks. These range from minor infractions, such as dialing fake phone numbers to increase long distance bills, to major problems, such as deletion of confidential information on the phone (the user's unique ID, for example) or, in the case of smart card–enabled phones, stealing credit card information or other sensitive data.


J2ME

Now that we have investigated a popular wireless markup language, we will look at a more robust language designed to run applications on limited devices without regard to operating system. Java is a versatile programming language. Sun's Java 2 Programming Language consists of three versions:

1. Java 2 Enterprise Edition

2. Java 2 Standard Edition

3. Java 2 Micro Edition

The version we focus on in this text is, of course, Java 2 Micro Edition (J2ME). By way of introduction, we take a brief look at the overall structure of Java. For various reasons, Java is a highly utilized language for many applications. It is object-oriented, has automatic garbage collection and exception handling, and allows multithreading. For those familiar with C++, it has similar syntax and is also object-oriented.

We mentioned that Java is designed to run without regard to the operating system. In wireless programming, this is not necessarily an advantage. In the wireless world today, application development is device-specific and operating system–specific more often than not. The ability to port one application across operating systems is not often seen. J2ME is not available on all devices or platforms. Thus, porting and device-specific code are a viable way of implementing wireless applications. This is rapidly changing with the release of Motorola phones that support J2ME and personal Java.

Components of Java

For those of you not acquainted with Java, this section provides a high-level overview so that you can gain a basic level of familiarity with Java terminology and functionality. The two major components of the Java Runtime Environment (JRE), the part of Java that makes a program run, are its execution engine and several runtime libraries. The Java Virtual Machine (VM or JVM) is the core of the execution engine. Virtual machines enable coders to run a program on any architecture just by porting the VM. The capability to move a VM from one architecture to another to run a program on multiple physical or logical architectures is why Java is so portable. The VM alone does not provide complete portability. Portability is achieved through the assistance of the class file format and the standard runtime libraries.

The JVM gets its specifications from the Java Virtual Machine Specifications (JVMS), available from www.sun.com. The JVM is given instructions for operations termed bytecodes. Bytecodes can be separated into two categories:

1. Bytecodes for operations that any machine architecture supports (for example, reading and writing memory, simple arithmetic operations)

2. Bytecodes specific to the Java language

The javap tool, available as part of Sun's Java Development Kit (JDK), enables you to see how Java code is translated into bytecode.

The Java class file format is the required format for bytecode to be input into the VM. The class file format greatly aids in portability. The JVMS takes care of the differences in a class file from one architecture to another. If you input a class file to the VM compiled on architecture A, it can be moved to a machine of architecture B without modification.

The garbage collector is an important feature of Java. There is no Java keyword used for deallocating objects. Instead, the garbage collector is in charge of reclaiming unused memory. Certain pros and cons are associated with automatic garbage collection, rather than requiring programmers to deallocate objects explicitly. Java programmers have little control over garbage collection, but they can develop certain habits to make the process more efficient. For instruction on these habits, you can consult a well-respected Java programming resource. Especially when designing a wireless program, you will find this worth understanding and implementing correctly. Making applications efficient becomes increasingly important as the limitations on the device itself, due to architecture, become more stringent.

The class loader is the component that helps the VM locate the classes it needs for a given application. There are two categories of class loaders. System class loaders store the essential runtime classes and the application classes when necessary. The classes are put into memory so that the virtual machine can access them. User class loaders (nonsystem class loaders) help provide application-specific methods of finding class files. For example, a WAP browser could load a class loader that gets classes from Wireless Transport Protocol (WTP) from a WAP gateway and a Web server. Class loaders store loaded classes to save the costs associated with retrieving classes when they are referenced.

The class verifier processes a class after the class loader loads it. The verifier serves an important purpose: It checks the bytecode for illegalities (ensuring that classes are well formed and that the bytecode follows the Java-specified typing rules), checks that enough stack is allocated for each section of code, and so on. The verifier is one defense against malicious programs. It can prevent unwanted or unrecognized classes from being placed on a device without the intended application's prior consent.

The last component of the execution engine we will visit in this chapter is the native code interface. This last component ties Java to the architecture's operating system. It defines how the virtual machine calls native code and how native code makes calls back into the execution engine to create new objects, invoke methods, or set and get field values.

The last component in our brief Java tutorial is the Java runtime libraries. We mentioned earlier that these libraries aid the VM and the class file format in establishing Java's hallmark—portability. Java depends on these libraries for interacting with the system and to provide useful shortcuts to standard programming tasks. This veritable shorthand saves programming time and allows for standardization across developers' implementations. There are various groups of runtime libraries, and the functions of some blur the lines between Java and the libraries themselves. The core of the Java runtime library is the java.lang package. Some of its classes are referred to directly by the JVM. They are usually initialized as defaults, along with other core classes, at start-up:

· Object. Is the root of all class and interface hierarchies

· Class. Defines information about a class

· ClassLoader. Loads classes

· String. Stores string constants

· Throwable. Declares and throws exception information

Flavors of Java

Over the past several years, Java has unfolded into many different flavors. Figure 5.1 illustrates the relationship among some. Early versions of Java focus on different kinds of programming. Java 1.2, the current version (familiarly called Java 2 as a marketing ploy more than a version control number), was designed for Enterprise programming. Java 1.02, the first public version, focuses on client programming; Java 1.1 focuses on server programming.

Figure 5.1. Different flavors of Java

Java 2 has a unique naming convention from Java 1.x. Recognizing the need for different sizes and functions of Java, Java 2 is available in several flavors. Within the Java 2 version are several groups of core APIs, which make up the different editions. The veritable plethora of programming interfaces is overwhelming. Many of these APIs are defined and controlled by entities outside Sun's realm. Sun recognized that it could not develop APIs fast enough to keep up with demand, so it enabled these external groups to do so by developing the Java Community Process. External groups develop APIs that are publicly available as long as they comply with Sun's Java API requirements. Sun does not, however, include every API in its core. Sun decided to formalize the usage of its extra APIs by defining standard extensions. Some extra sets of APIs that are useful only to subsets of the Java community are available as extensions to the core APIs—at an extra charge. Java 2 is also divided into three editions:

· Java 2 Standard Edition

· Java 2 Enterprise Edition

· Java 2 Micro Edition

Java 2 Standard Edition

J2SE targets much the same programs as earlier versions: basic client or server applications that do not require special APIs or interoperability with other object models or languages. J2SE is much too large for limited-capability devices such as wireless clients. One noteworthy feature of J2SE is its HotSpot execution engine (see http://java.sun.com/products/hotspot for a detailed description), designed to make Java more expedient. HotSpot is more discriminating in optimizing code than its predecessors and includes an improved garbage collector. Two versions of this new addition are available, HotSpot Client VM, geared towards use on clients where applications start easily, and HotSpot Server VM, geared towards use where applications are likely to be more intensive and taxing on a machine and are therefore server-side, where more optimization at start-up is possible.

Java 2 Enterprise Edition

J2EE subsumes J2SE. It is designed to meet the needs of enterprisewide programming and applications. J2EE is ideal for applications that must be available to thousands of clients, are largely server-based, and must be capable of interacting with legacy systems. J2EE allows large-scale applications to be deployed more easily than J2SE and with increased security. At the risk of blatancy, J2EE is also far too large for use on wireless clients. For more information on J2EE, consult its home page at http://java.sun.com/j2ee.

Java 2 Micro Edition

Finally, the Java 2 Edition important to wireless developers: Java 2 Micro Edition. J2ME selectively rewrites and removes integral components of the core runtime environment to make it easily portable to smaller constrained devices. Sun Microsystems' J2ME made its debut in June 1999. Almost shadowing this announcement was the introduction of its counterpart, a new virtual machine that could run simple Java programs on Palm OS devices. The specifications were not quite ironed out at this point, so the actual debut (and availability to the public) was not until the summer of 2000 after the specifications were finalized.

The new virtual machine, called the KVM, is optimized for small devices and makes possible much of the wireless development that occurs today. We will investigate the KVM shortly. The KVM (an abbreviation for an early name, Kuaui VM) runs well in a constrained environment. You can use the JVM in J2ME, and you would choose to do so when working in a 32-bit environment with a generous amount of memory. The KVM is used in a J2ME architecture where the architectures are either 16-bit or 32-bit and have limited memory.

Class Differences

J2ME is not a new form of Java. If an application is developed for J2ME, it is compatible with J2SE or J2EE, provided that the environments include the same extra APIs. J2ME works (mostly) seamlessly on a variety of devices. A big factor in being able to use this edition of Java on smaller platforms is to reduce the number of classes used. Some classes are left out by default, and others are reduced through a process that eliminates redundancies in methods. This constructs an actual subset of the J2SE runtime classes. The differences do not end in merely a reduction in size, however. If necessary, any classes that are part of the classic runtime environment can be stored in the VM's internal format instead of the normal class file format. Note, however, that user-defined classes must be readable in the normal class file format. Some of the classes that are eliminated at the start in J2ME provide ways of interacting with the external devices. J2ME therefore includes new classes tailored to meet the needs of the smaller devices for which it is selected.

Beyond the new and changed set of classes, we will discuss three components of J2ME:

· The virtual machine (KVM)

· Configurations

- Connection Limited Device Configuration (CLDC)

- Connected Device Configuration (CDC)

· Profiles

- Mobile Information Device Profile (MIDP)

- Others under development (PDA, Foundation, Personal)

Each item listed here contributes to enabling portability across a variety of limited resource devices.

K Virtual Machine

Our perusal of the smallest of the Java 2 versions begins with the KVM. The KVM is a small-footprint virtual machine for resource-constrained devices. It accepts almost the exact same set of bytecodes and class file format that the regular VM does. The goals in designing the KVM were that it be easy to understand and maintain, highly portable, and limited in size without sacrificing essential Java features. The KVM is a less fancy version of the JVM. It does not boast dynamic compilation or other more advanced performance optimization techniques. The KVM only runs at roughly half the speed of JDK 1.1 software without an improved compiler. The KVM does boast portability. Its release includes three choices of ports:

· Win32

· PalmOS (3.01 and up)

- Solaris

Sun's external partners have ported it to still other platforms, totaling just fewer than 30. Unlike some other limited Java implementations, the KVM supports dynamic class loading and regular class files, as well as a full Java technology bytecode set and JAR file formats.

As far as compatibility with the JVM, KVM's general goal is that it be fully compatible with the JVMS and Java Language Specifications. The main differences are found in the language levels. No hardware floating-point support exists on most resource-constrained devices because of space limitations, so the Connection Limited Device Configuration (CLDC) (which runs on top of the KVM and is discussed in detail in the next section), does not include floating-point support. The exceptions to total compatibility also include the fact that limitations prevent the use of the full J2SE platform security model and that the libraries included with CLDC are limited. For those of you more familiar with full-blown Java, the implementation differences of the VMs are that no JNI, reflection, thread groups, weak references, and finalization are included, as well as limited error handling support and a new implementation of bytecode verification.

The KVM garbage collector component is small and simple. It is nonmoving, nonincremental, single-space, designed to limit recursion, and optimized for small heaps (32–512K). Sun intends to release an alternative, more advanced garbage collector in the future. The advantages of the KVM garbage collector are that it does not move objects, allowing for a simple and clean code base, and that it uses less memory. The disadvantages inherent to the KVM are that object allocation is slower, memory fragmentation can cause it to run out of heap, and it induces latency when using large heaps in garbage collection, because it is nonincremental.

Configurations

To conceptualize the logical organization of J2ME, you have to understand more than just its virtual machine. You must understand the J2ME concepts of Configurations and Profiles. A configuration is composed of a virtual machine, core libraries, classes, and APIs. It specifies a general runtime environment for consumer electronic and embedded devices and acts as the Java platform on the device. A profile is an industry-defined specification of the Java APIs used by manufacturers and developers to address specific types of devices.

Configurations define the minimum capabilities and libraries for a virtual machine for the Java platform that will be available on all devices belonging to a family. All these devices will possess similar memory requirements and processing power. There are currently two specified configurations in J2ME: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). Both configurations are the results of Java Community Process efforts.

Connected Limited Device Configuration (CLDC)

The CLDC has standardized a portable, minimum-footprint Java chunk for resource-constrained devices. The CLDC configuration provides for a virtual machine and a set of core libraries for use in certain profiles that define requirements for given devices. One such profile, the Mobile Information Device Specification's Profile (MIDP), uses this configuration in designing applications for wireless or handheld devices. Accord-ing to Sun's community Web site describing the CLDC, the devices generally targeted with CLDC are characterized as follows:

· 160–512K total memory (including both RAM and flash or ROM) is available for the Java platform.

· Power is limited (often powered by battery).

· Connectivity to a network is often intermittent (and/or wireless).

· Bandwidth is expected to be limited, 9600bps or less.

· User interfaces are primitive, with variable degrees of usability.

The most recent CLDC version includes several improvements over its immediate predecessor. It has a faster bytecode interpreter, an exact, compacting garbage collector, Java-level debugging APIs, and preverifier improvements, among others. This release also includes an implementation of CLDC for the Linux operating system. The static size of the CLDC platform, including both the VM and the libraries, is usually less than 128K. In addition to virtual machine and language features, CLDC specifications cover input/output, networking support, internalization, and a security model. Several components that you might expect to be there are intentionally omitted: application installation, user interface support, event handling, a high-level application model, and database support. These features are, instead, defined in a profile.

CLDC security is different from traditional Java security. CLDC defines low-level virtual machine security that protects the device from harm and guarantees a certain level of security by the class file verifier. Because the size of the J2SE class file verifier is larger than the entire KVM, CLDC/KVM has its own class file verifier. This class file verifier introduces a two-pass method. To save time and processing cycles, the verification is done on a desktop or server computer where the class files are compiled, rather than on the device. This off-device verification is termed preverification. The device performs some simple operations to confirm that the class file was verified and that it is still valid. The CLDC class file verification does not require code signing.

CLDC security also defines a sandbox model similar to that of other Java editions that creates application security. The sandbox model defined in J2SE is far too large for limited devices. The sandbox security in CLDC does serve similar functions, though. It requires that class files be properly verified and affirmed valid Java applications. Only the predefined set of Java APIs used in CLDC is allowed to execute. In the sandbox model, only the device can download and install applications. Applications are not allowed to download individual classes.

The classes CLDC inherits from J2SE are in three packages: java.lang.*, java.io.*, and java.util.*. They are listed in Table 5.2. All new classes introduced are parts of javax.microedition.io.*.

Standard J2SE networking, I/O, and storage libraries are too large for CLDC devices. Original classes assume that TCP/IP is available and are not easy to extend to support new protocols (for example, Bluetooth). Instead, CLDC introduces a new generic connection framework. It allows for better ease in supporting different types of networking protocols, is more easily extensible, and is upwards compatible with standard Java class libraries. A general connection, for example, would take the form of

Table 5.2. Inherited Classes

Package

Class

java.lang

Boolean, Byte, Character, Class, Integer, Long, Math, Object, Runnable, Runtime, Short, String, StringBuffer, System, Thread, Throwable

java.io

ByteArrayInputStream, ByteArrayOutputStream, DataInput, DataInputStream, DataOutput, DataOutputStream, InputStream, InputStreamReader, OutputStream, OutputStreamWriter, PrintStream, Reader, Writer

java.util

Calendar, Date, Enumeration, Hashtable, Random, Stack, TimeZone, Vector

Connector.open("<protocol>:<path>;<parameters>");

A connector used in HTTP would take the form of

Connector.open("http://www.usa.com");

A connector used in opening a serial port would take the form of

Connector.open("comm:0;baudrate=9600");

CLDC does not define any network protocols, just the framework for their interaction. Profiles define the specific protocols that device categories support.

Connected Device Configuration (CDC)

The CDC defines a set of items that compose a portable Java chunk for consumer electronic and embedded devices. The CDC configuration provides for a virtual machine and a set of core libraries appropriate for use with industry-defined profiles for less limited devices, such as the Foundation Profile. According to the Sun community Web site describing the CDC, target devices are characterized as follows:

· They are powered by a 32-bit processor.

· They have 2MB or more of total memory (including both RAM and flash or ROM) available for the Java platform.

· They require the full functionality of the classic JVM.

· Connectivity to a network is often intermittent (and/or wireless).

· Bandwidth is expected to be limited, 9600bps or less.

· User interfaces are primitive, with variable degrees of usability.

As you can see from this list, the differences in the target devices for CLDC and CDC are that CDC target devices are powered by more powerful processors, have more total memory, and make use of the full-blown JVM. The CDC contains the full JVM, the CVM virtual machine, and the class libraries and APIs necessary to get the system up and running. For an application to be meaningful, this configuration requires the help of a profile. At this time, only one profile, the Foundation Profile, is used in CDC. Because CDC subsumes CLDC, any CLDC-compliant profile can be used in CDC.

The CDC class library contains the following packages from J2SE:

· java.lang

· java.util

· java.net

· java.io

· java.text

· java.security

CDC uses a subset of the J2SE APIs, eliminating nonessential ones to conserve space and performance cycles. CVM combines minimalist features inherent to the KVM with more enhanced features of the JVM, such as a precise memory system, an advanced garbage collector, and better Java synchronization. CVM supports multiple porting and is implemented in C. CVM can run with mostly preloaded classes concurrently with dynamically loaded classes. This allows for quicker start-up time, less latency, and the capability to execute bytecodes out of ROM. CVM provides interfaces between garbage collection, the type system, and the interpreter. These interfaces are clearly defined and well separated.

Now that you have learned about configurations, it is appropriate to introduce two profiles that give these configurations specificity and increased ease of portability.

Profiles

A profile is more application-oriented, whereas a configuration is more device-oriented. As mentioned earlier, a profile is an industry-defined specification of the Java APIs used by manufacturers and developers to address specific types of devices. A profile supplements a configuration to provide capabilities common to a certain device category. Currently, two profiles have completed the Java Suggested Revision (JSR) process that is part of the J2ME-approved specifications. The Mobile Information Device Profile (MIDP) is used with CLDC, and the Foundation Profile is used with CDC.

Mobile Information Device Profile (MIDP)

The CLDC does not define any user interaction parameters in its specifications. This is left to profile definitions. The MIDP is designed to run on Mobile Information Devices (MID). A MID is defined as having the following features: a display that is at least 96 pixels by 64 pixels; a touch screen, keypad, or keyboard; a wireless network connection (either always on or intermittent); 128K of nonvolatile memory for MIDP, 8K of nonvolatile memory for persistent data, and 32K of volatile memory for the Java runtime; and the capability to run the VM and low-level APIs for obtaining user input. The MIDP adds APIs to the CLDC for the following functions:

· Displaying text and graphics

· Responding to user events

· Defining and controlling applications

· Storing data in simple databases

· Network connectivity via a subset of HTTP

· Timer notifications

The MIDP necessarily excludes details for

· Downloading applications

· Installing applications

· Network security

The Foundation Profile

According to its specifications, the Foundation Profile is simply a set of Java APIs tailored to complement the CVM in the CDC. Together, these provide a complete J2ME runtime environment for devices that are limited but have 2MB or more memory and a 32-bit processor. The profile tweaks some of the packages in J2SE to provide necessary support for critical functions on limited devices.

The Future of J2ME

J2ME targets a wide range of uses and devices that differ greatly from one another. Currently, profiles are developed for specific categories of devices. The MIDP targets devices such as cell phones. The intention behind profiles is that J2ME application developers utilize certain profiles so that their applications can port easily across any device that implements the profile. The proposed inclusion of building blocks will define an API derived from J2SE or J2EE APIs for use in J2ME. According to the Java Community Process Java Specification Request for this change, a building block might define a specific set of classes from java.io. The building blocks will then be available for Profile Expert Groups to use in developing new profiles. The more far-sighted intent for building blocks is that they will eventually cause configurations to fall into extinction. At the time of the writing of this text, both configurations discussed here are standard operating procedures for J2ME, as are several profiles, but Sun is in the process of visiting the proposal for building blocks. Several profiles are currently in various stages of approval. There are proposals for a PDA profile, a Personal profile, an RMI profile, and a Java TV profile. Refer to Sun's J2ME Web site for updates on these proposed profiles, at http://www.sun.com/software/communitysource/j2me.


Part III: Protect Your System

Chapter 6. Cryptography

Chapter 7. COTS

Chapter 8. Privacy


Chapter 6. Cryptography

Only amateurs attack machines; professionals target people.

—Bruce Schneier

The purpose of this chapter is not to make you an expert in cryptography but to give you a basic overview, focusing on the most important issues to wireless developers. After reading this chapter, you should have a general understanding of the following:

· What applied cryptography is (and is not)

· What it can (and cannot) accomplish

· How it should (and should not) be used

· What a secure encryption mode looks like

· Which common pitfalls are associated with the use of cryptography in secure applications

This chapter is based on the unpublished work Introduction to Applied Cryptography by Tadayoshi Kohno ( tkohno@acm.org ). We have simplified certain concepts to make them more understandable to the noncryptographer. Therefore, it would be a mistake to read this chapter and then go off and spin your own cryptographic algorithms. Portions of this chapter may delve beyond the extent of your mathematical knowledge, or some concepts may be difficult to grasp. However, there are two primary lessons to be learned and kept in mind when working with cryptographic issues:

1. Cryptography is not security. In particular, application security is more than just cryptography. Strong cryptography is usually a prerequisite for secure applications, but the mere use of cryptography cannot guarantee that an application will be secure.

2. Cryptography is not easy. Because cryptography is so difficult (yet so important for the security of many applications), developers should not invent their own cryptographic algorithms. They should use only well-known, trusted algorithms in their applications. When this is not possible, they should seek the advice of experienced cryptographers.


Applied Cryptography Overview

To demonstrate the concepts in this chapter, we will use the office complex case study from Chapter 1, "Wireless Technologies."

The Office Complex Case Study

An advertising corporation, AdEx Inc., has installed a wireless LAN system throughout its multistory building in Reston, Virginia. It has installed access points at key locations to provide complete coverage throughout the building. Employees are given laptop computers with docking stations at their work areas. Both the docking stations and the laptops are equipped with wireless LAN access devices. The conference rooms are equipped with projection systems connected to the LAN so that employees can take their laptop to a conference room, connect to the projection system over the network, and control a presentation via their laptop.

An AdEx sales team, headed by Kathleen, is proposing a new marketing campaign to a potential new client, NitroSoft. The team has been working on this presentation account for several weeks. Before the presentation, Kathleen takes the NitroSoft group to lunch. During lunch, the NitroSoft people receive a message on their PDAs announcing a new acquisition that has relevance to the team presentation. One of the people in the NitroSoft group, Louis, mentions the announcement to Kathleen, who takes out her PDA and asks him to send her a copy of the announcement. Louis sends a copy to her PDA, with additional background information. Kathleen forwards it to one of her staff members, with instructions on how to incorporate the new information into the presentation.

After lunch, the group returns to AdEx and proceeds to the conference room for the presentation. On the way, Kathleen checks her PDA and receives word that her team will be able to incorporate the new information but that it will take 20 more minutes. They inform her that the changes fit well in the second half of the slides. Kathleen says that she will begin with the original presentation and switch to the new presentation half way through if they complete it and are satisfied with the results. Otherwise, she will stick with the original presentation.

Kathleen and the NitroSoft group reach the conference room and settle in for the presentation. The AdEx sales team continues working as Kathleen begins the presentation. As she talks, she monitors her PDA and receives confirmation that the team has incorporated the new information and is satisfied with the result. At a convenient point, Kathleen pauses, loads the updated slides, and switches to the new presentation. The NitroSoft group is impressed by the efficiency and speed with which the team incorporated the new information. AdEx and NitroSoft close the deal that day.

Imagine that the relationship between AdEx and NitroSoft is not cordial. In fact, let us say that AdEx and NitroSoft are hostile to or competing with each other. Louis and NitroSoft need to communicate securely. Unfortunately, they must communicate over inherently insecure (and potentially hostile) channels (AdEx's network). Kathleen is a malicious party who wants to spy on or tamper with their conversations. Figure 6.1 depicts the relationship we will use for examples throughout this chapter.

Figure 6.1. The overt relationship between Louis, NitroSoft, AdEx, and Kathleen

What does communicating securely mean for Louis and NitroSoft, particularly if they must communicate over hostile channels? It means that even if their messages are transported over an insecure medium (such as AdEx's network or the Internet), it should be as if they were communicating directly with each other over a dedicated and physically secure channel that they completely control. If the communications channel is secure,

· No one can listen to their communications.

· No one can modify or tamper with their communications.

· Both know that they are communicating with each other and not with an impostor.

· Louis cannot deny that he sent a message to NitroSoft, or vice versa, at a later date.

These requirements for secure communications serve as goals for applied cryptography. They are also, not surprisingly, four of the six security principles discussed in Chapter 2, "Security Principles": Privacy and Confidentiality, Integrity, Authentication, and Nonrepudiation. Here is the meaning of these principles in the context of the office complex scenario:

· Privacy and confidentiality. Kathleen should not be able to learn anything about the contents of a message Louis sends to NitroSoft.

· Integrity. Kathleen should not be able to trick NitroSoft into believing that information she sends came from Louis; she should not be able to modify, undetected, a message Louis sends to NitroSoft.

· Authentication. Louis should be able to convince NitroSoft that it is communicating with him; Kathleen should not be able to trick NitroSoft into believing that she is Louis.

· Nonrepudiation. After committing to a transaction, Louis should not, at a later date, be able to claim that he did not commit to that transaction.

Cryptographers use many tools to accomplish these security goals. An encryption algorithm is a cryptographic protocol Louis and NitroSoft can use to establish privacy. Figure 6.2 depicts the process. Encryption is the process that transforms an understandable message into a form that only a legitimate recipient can read. The initial (readable) message is called the plaintext, and the resulting garbled (unreadable) message is called the ciphertext. Decryption is the process of retrieving the original plaintext message from the ciphertext.

Figure 6.2. The encryption/decryption process

Traffic Analysis

It is worth emphasizing why these security principles are called goals and why encryption in and of itself may be insufficient. Take Privacy and Confidentiality, for example. The preceding states that Kathleen should not be able to learn anything about the contents of a message Louis sends to NitroSoft. You may be saying that, if it is encrypted properly, this is true. Not so? You must consider traffic analysis as well. Traffic analysis is the art and science of examining communication patterns to derive meaning from otherwise meaningless communications.

For example, let us say that Louis must receive approval for any deal before he can sign. Further, let us assume that NitroSoft has a process in place for evaluating proposals and receiving approval for the expenditure. The approval process takes ten minutes, and if the proposal is approved, notifying Louis and processing the necessary paperwork for signatures take five more minutes. By timing the response, Kathleen can derive information from the exchange without being able to read the message. This is a simple example, but the point is that you can gain a lot of information—by watching traffic volume, the length of messages, and the like—which encryption by itself does not protect.

Primitives and Protocols

Primitives are algorithms or procedures to accomplish a computing task, such as converting plaintext to ciphertext or converting ciphertext to plaintext. Protocols are processes or procedures to accomplish communications between entities. An encryption protocol is the process of encrypting plaintext into ciphertext so that the intended recipient can decrypt the ciphertext and retrieve the plaintext. There are numerous cryptographic algorithms and protocols. The following examples are frequently used cryptographic methods that do not fall strictly into the encryption or decryption category:

· A message authentication code (MAC) is an algorithm to generate a code that can be used by a protocol to establish the authenticity of a message between to entities.

· A key agreement algorithm is part of a protocol that can be used by two entities to compute a shared secret (a key or another token known only to them) even if they cannot communicate over a secure channel.

· A digital signature is an algorithm used by an entity to sign an electronic message; the protocols of this algorithm are the process of signing a message and verifying the signature at the destination.

A set of cryptographic protocols forms a library of useful cryptographic tools. These tools, used appropriately, can help a developer create secure applications. The thing to remember is that cryptographic primitives are used to produce cryptographic protocols; these protocols are used in turn to generate secure applications. Figure 6.3 depicts this relationship. Developers should not use primitives; used by themselves, primitives may be insecure.

Figure 6.3. The relationships between primitives, protocols, and applications

Symmetric and Asymmetric Algorithms

Conventional cryptographic algorithms use what are called keys. A key is electronically represented information that affects the execution of an encryption or decryption algorithm. A keyed algorithm produces different output for different keys. Figure 6.4 depicts an encryption algorithm that takes two inputs, the original plaintext and an encryption key, and produces one output, the ciphertext. Using a different key as one of the inputs produces a different ciphertext. The decryption algorithm also takes two inputs, the cipher text and a decryption key, and produces a single output, the plaintext (if the decryption key is correct).

Figure 6.4. The encryption process with keys

An encryption algorithm is symmetric if the encryption key is the same as the decryption key. Using a symmetric protocol, Louis and NitroSoft share the same symmetric key, or shared secret. To send a private message to NitroSoft, Louis encrypts the message with the shared symmetric key, and NitroSoft decrypts that message with the same symmetric key.

An encryption algorithm is asymmetric if the encryption and decryption keys differ. One use of asymmetric keys is public/private key cryptography, in which each person has a private and a public key. Using a public/private key protocol, if Louis wants to send a private message to NitroSoft, he encrypts the message with NitroSoft's public key, and NitroSoft then decrypts the message with its private key. Although NitroSoft must maintain the secrecy of its private key, it can give the public key to anyone it chooses (including Kathleen). NitroSoft could even publish the public key in a public directory or phone book. A big advantage of asymmetric cryptographic protocols over symmetric cryptographic protocols is that Louis can obtain NitroSoft's public key from a public directory and send NitroSoft a secret message without ever meeting face to face with anyone at NitroSoft (that is, without ever agreeing on a shared secret symmetric key).

Cryptographic Attacks

To understand fully how to use cryptography in a wireless (or other) application, a developer must understand who her application's adversaries are. In the example, the developer must understand how Kathleen thinks and which techniques she might use to circumvent the security of an application.

Cryptography plays only a small role in an application's security. Certainly, if an application uses bad or weak cryptography, it will be exploitable. However, even if an application uses strong cryptography, it may still be insecure. For example, a privacy application might use a strong encryption algorithm but store the algorithm's decryption key in plaintext in a buffer that can be used to pad information transmitted, thus leaking the key to Kathleen. (Application security is stressed in later chapters.)

Types of Attacks

Consider how Kathleen could attempt to break (attack) an encryption algorithm. Recall that an encryption algorithm is a protocol utilizing keys designed to protect the privacy of information. Kathleen can break an encryption algorithm if she can learn any information about the plaintext corresponding to encrypted ciphertext. By this, we mean learning any information about the plaintext: the number of 1 bits in the plaintext, the value of the fifth bit, or the entire message.

To obtain information about the plaintext, Kathleen can try every possible decryption key until she finds the correct one. This is called a brute force or exhaustive key search attack. When Kathleen learns the decryption key, she can decrypt the entire ciphertext and any subsequent ciphertext transmitted.

Rather than mount a brute force attack, Kathleen could try to exploit an obscure property of the algorithm itself. Such an attack is referred to as a smart or shortcut attack. Although shortcut attacks typically require less time than brute force attacks, they may be less practical in the real world (for example, they can require an exorbitant amount of memory or observed ciphertexts).

What would Kathleen's attacks look like? There are two general types of attacks: passive attacks and active attacks. In a passive attack, Kathleen would simply listen to and record the communications between Louis and NitroSoft. After collecting enough data, she could perform some computation and try to break the protocol between Louis and NitroSoft. In an active attack, Kathleen would actually interfere with the communication between Louis and NitroSoft. She could do the following:

· Prevent NitroSoft from receiving some of Louis's messages.

· Modify some of Louis's messages in transit.

· Save some of Louis's messages and resend them at a later date (commonly referred to as a replay attack.

· Pretend to be Louis to NitroSoft and NitroSoft to Louis (the man in the middle).

Costs of Attacks

Almost all modern cryptographic protocols are breakable in theory. Given enough time and resources, you could break virtually any cryptographic protocol. The question is not whether someone can break a cryptographic protocol but whether it is practical in real life. This aspect of breaking cryptography leads cryptographers to classify an attack against a cryptographic algorithm by the attack's requirements. The more practical an attack, the more susceptible an algorithm is to that attack.

The other aspect is cost: how much memory or how long it will take. Does the attack algorithm run in minutes, days, years, or centuries? The more time required, the less vulnerable the cryptography. Thus, the measure of an attack's cost gives an indication of the attacked encryption algorithm's strength.

Of course, even if all known attacks against an algorithm currently require too much time or memory to execute, advances in scientific research, or computing power, will yield considerably faster attacks. For example, in the 1970s, single 56-bit key DES was considered secure enough to protect sensitive information. Now these keys can be brute-force attacked in hours on a network of standard desktop personal computers.

Another aspect of an attack's requirements is the information necessary. Because we are considering attacks against an encryption algorithm, we might ask how much ciphertext is required for analysis or whether knowledge of part of the plaintext is required. The more information required by an attacker, the less likely an attacker will be able to mount a successful attack.

Large Numbers

We close this section with a discussion of large numbers. In the preceding subsection we mentioned that a cryptographic algorithm may be considered secure if it is unfeasible for an attacker to mount an attack in practice. Perhaps it takes too much time, consumes too much memory, or requires too many ciphertext samples. But how much is too much? We will answer that question in the section " Choices ." For now, let us point out that too much is usually a very large number on the order of 2128. So that you can put these large numbers in context, and for future reference, see Table 6.1 . This table is taken from Applied Cryptography: Protocols, Algorithms, and Source Code in C, by B. Schneier, John Wiley and Sons, second edition, 1996.

Table 6.1. Examples of Large Numbers

Physical Analogue

Number

Years until next ice age

214

Age of the Earth in years

230

Age of the Universe in years

234

Number of atoms in the Earth

2170

Number of atoms in the Sun

2190

Number of atoms in the galaxy

2223


Symmetric Cryptography

Symmetric cryptography is a cryptographic method employing a single key for both encryption and decryption. The use of a single key makes the decryption process a simple reversal of the encryption process. Symmetric cryptography is the cryptographic method most often thought of when people consider classic cryptographic techniques, such as one-time pads (which we cover in the section "Stream Ciphers").

Symmetric Primitives

In this section we will describe some of the most important primitives and protocols used in today's cryptographic applications. Recall that cryptographic primitives are the building blocks for cryptographic protocols and for secure applications. Although cryptographic primitives by themselves do not provide useful functionality and should not be used by application developers, an understanding of these primitives is helpful in understanding the protocols.

Block Ciphers

Block ciphers are among the most important, powerful, and useful cryptographic primitives. They serve as the backbone for many cryptographic protocols. Although most of you do not need to understand the inner workings of block ciphers, you should understand the external behavior of block ciphers.

A block cipher consists of a pair of algorithms: an encryption algorithm and the inverse, a decryption algorithm. These algorithms, respectively, accept a plaintext (or ciphertext) message and a key as input and produce a ciphertext (or plaintext) message as output. For any given block cipher, the size of the plaintexts and ciphertexts is the same fixed value (called the cipher's block length). That is, a block cipher would convert 64-bit (8-byte) plaintext blocks into 64-bit ciphertext blocks. To encrypt messages longer than the block length, you must wrap the block cipher in a higher-level protocol, which we will cover shortly.

For any given key and plaintext block, a block cipher encryption algorithm will always produce the same ciphertext block. Similarly, for any given key and ciphertext block, a block cipher decryption algorithm will always produce the same plaintext block. The block cipher's encryption and decryption algorithms are complementary. Different keys (with very high probability) produce different encryptions and decryptions. A plaintext encrypted under one key yields a different ciphertext than the same plaintext encrypted under a different key. For any given key, a block cipher should appear to be a random mapping between possible plaintexts and ciphertexts. That is, an attacker should not be able to tell the difference between a block cipher encryption and a purely random string.

Obviously, keys play an integral role in the security of a block cipher. If an attacker acquires a key, she can encrypt or decrypt blocks with that key. We are assuming that the encryption algorithm is known or determinable; in most cases, this is true. Therefore, not only must an application keep its keys secret, but it must also be prohibitively difficult for an attacker to randomly guess a particular key or try a brute force attack. One way to ensure that an attacker will have difficulty guessing a particular key is to increase the number of bits in a key, making the number of possible keys very large.

If a block cipher uses k-bit symmetric keys, there will be 2k possible keys for that block cipher. This means that an attacker will have to try 2k keys before she finds the correct one. In reality, the attacker may be lucky and the first key will be correct, or she may have to try all 2k keys. On an average, the attacker would have to make 2k–1 guesses. This is for strong block ciphers where brute force is the most efficient attack; weaker block ciphers may have more efficient attacks. Key length has less effect on these other attacks. These issues are not specific to block ciphers; key length affects the strength of all ciphers.

Although there are many block ciphers, we shall give further consideration to the three most popular: DES, 3DES, and AES. Published in the 1970s, DES is the U.S. Government's Data Encryption Standard. DES has a block size of 64 bits and a key size of 56 bits. Despite its relatively small block and key sizes, DES is an incredibly well-engineered cipher. Although there are a number of theoretical attacks against DES, the most practical attack is still a brute force attack of trying all 256 (or more than 72 quadrillion) keys.

Even with this large number of keys, brute force attacks against DES are now possible with today's networking and desktop computing power. Thus, the adoption of 3DES (or triple-DES). Triple-DES consists of three chained DES operations (see Figure 6.5):

Figure 6.5. The triple-DES process

1. Encrypt the plaintext with key K1.

2. Decrypt with key K2.

3. Encrypt again with key K3.

This is known as three-key 3DES. There is also a two-key 3DES, in which K1 and K3 are the same. The key size for two-key 3DES is 112 bits, and the key size for three-key 3DES is 168 bits. Unfortunately, certain attacks against two-key 3DES are significantly faster than brute force. Proving that, even if you take a very strong primitive and implement it correctly, its implementation may be vulnerable.

In the mid 1990s the U.S. Government's National Institute of Standards and Technology (NIST) began the process of selecting a new U.S. Advanced Encryption Standard (AES). Because of DES's vulnerabilities (due to its small key and block sizes and slow performance), AES is to replace DES and be computationally efficient and secure. After several years and numerous technical meetings, NIST has picked a cipher called Rijndael (pronounced "rhine-dahl") to be the AES. Rijndael is configurable; versions of Rijndael exist for any combinations of appropriate key sizes (128, 192, or 256 bits) and block sizes (128, 192, or 256 bits).

Stream Ciphers

Stream ciphers are another very popular encryption primitive. They are typically much faster and simpler than their block cipher cousins (especially when implemented in hardware) and are therefore commonly used in systems that cannot handle the overhead associated with block ciphers (such as high-speed telecommunications systems). Unlike block ciphers, there is no clear, generally accepted, popular stream cipher. In fact, many of today's commonly used stream ciphers are proprietary.

Modern stream ciphers are modeled after the Vernam one-time pad (see Figure 6.6). The sender and receiver share a long sequence of random binary digits (the one-time pad). When the sender wants to send a secret message to the receiver, the sender XORs the first bit of the plaintext message with the first bit of the one-time pad. Then she XORs the second bit of the plaintext message with the second bit of the one-time pad, and so on. This process is continued until the end of the message is reached.

Figure 6.6. A one-time pad

XOR or Exclusive OR is represented by the symbol [image] and has the following properties:

0 [image] 0 = 0;

1 [image] 1 = 0;

0 [image] 1 = 1;

1 [image] 0 = 1

As you can see, XOR is a change indicator, meaning that the result is 1 only when the two bits are different.

To maintain the security of the system, a one-time pad (as the name implies) requires that its bits never be reused. After a bit is used from the one-time pad, it must be discarded. Provided a one-time pad is never repeated and is truly random, its encryption algorithm is perfectly secure. This means that even if an attacker has an unlimited amount of computing power at her disposal, she will be unable to learn anything about the plaintext message.

Although theoretically optimal from an encryption standpoint, in practice the one-time pad is not very useful. Because it must never be reused, it must be as long as the secret message to be encrypted. In fact, it must be as long as all the messages that may ever be sent. Even with great forethought, this is virtually impossible to do in practice.

Modern stream ciphers are an attempt to provide a practical version of the Vernam one-time pad. The heart of the modern stream cipher is a keystream generator. The keystream generator takes a small key (or seed) and generates a longer keystream. The resulting keystream is then used like the one-time pad. The premise behind stream ciphers is that it is much easier for two parties to agree on a small secret key (to produce the keystream) than to agree on an entire one-time pad. Unfortunately, these modern stream ciphers are not perfectly secure, and an attacker with enough resources can break the encryption. Most of the vulnerabilities lie in the fact that producing truly random bit streams using a computational method is very difficult. Developers and consumers should be very leery of stream ciphers or algorithms that claim to produce random numbers or random streams. The truth of the matter is that the best that can be accomplished computationally are pseudo-random numbers or pseudo-random streams.

Hash Functions

Cryptographic hash functions are another extremely important cryptographic primitive. Hash functions take as input a long string of bits (such as a message or file) and produce as output a smaller, compressed string of a fixed size. For example, the SHA-1 hash function produces 160-bit hash values, and the MD5 hash function produces 128-bit hash values. Unlike block ciphers and stream ciphers, hash functions do not utilize keys. This means that, given a specific input, anyone can compute the hash of the input.

Most cryptographic hash functions share the following properties:

· Pre-image resistance. It should be difficult for an attacker, when given a hash value, to be able to identify a stream that will produce that hash value. That is, if Z is an output of a hash function, it should be hard for an attacker to find a value X so that X hashes to Z.

· Second pre-image resistance. It should be difficult for an attacker to find a second stream for a given hash value that produces that hash value. That is, given a value X that hashes to Z, it should be hard for an attacker to find another value Y that also hashes to Z.

· Collision resistance. It should be difficult to find two different inputs that hash to the same value. That is, it should be hard for an attacker to find two values, X and Y, that hash to the same value Z. Here the attacker has complete control over the choice of both X and Y.

As with block ciphers and stream ciphers, hash functions are susceptible to brute force attacks. To brute-force a pre-image or second pre-image of a hash value Z, an attacker would repeatedly pick input strings and hash those strings until one of those strings hashes to Z. If the target hash function produced an n-bit hash value, an attacker would need to try nearly 2n strings before finding one that hashes to Z.

To brute-force a collision, an attacker would have to pick random input strings repeatedly until two of those strings hash to the same value. Because of a mathematical property dubbed the birthday paradox, an attacker would have to hash approximately 2n/2 strings before finding two strings that hash to the same value. Meaning, to prohibit these brute force attacks, secure applications should use hash functions with 160-bit or more hash sizes. (Again, this number will increase as processing power and available memory increases in readily available computing platforms.)

The Birthday Paradox

The birthday paradox is a problem of probability. Given a room with more than 23 randomly selected people, the probability that 2 people in the group have the same birthday is 50 percent. In other words, there is a 50/50 chance that 2 of those people have the same birthday. The paradox comes in because we normally consider only matching our birthday to someone else's, which is a 1/365 chance of matching, or .27 percent. Put another way, the probability of failure is (1 – .27%) = 99.73%. Each additional person we ask increases the chance by only 1/365 (an addition function), so asking 23 people increases the chance of matching to only 1/365+1/365 (repeated 21 more times), which equals 23/365, or nearly 6.3 percent—a very low percentage.

However, when you start comparing pairs in the group (that is, looking for any matching birth date), it becomes a different story because each person is comparing her birth date against the other 22 people (a multiplication function), or (23*22)/2 pairs, or 253 pairs. Although the probability of failure in the first case is 99.73 percent, in the latter case it is the probability of failure raised to the number of pairs, or .9973253 = .5046. The probability of success is 1 – .5046 = .4954, or approximately 49.5 percent.

In a large set of possible strings, finding a second string that hashes to the same value as a given string has a very low-percentage probability of success. Finding a pair of strings that hash to the same value within a large set of possible strings is not as difficult a task. However, if the set of possible strings is large, you still have to try many strings before the probability of success becomes reasonable.

Recently, the U.S. Government published three additional hash algorithms: SHA-256, SHA-384, and SHA-512. As their names imply, these new hash algorithms respectively produce 256-bit, 384-bit, and 512-bit hash values. Because the strength of an n-bit hash function against a brute force collision attack is about 2n/2 and the strength of a block cipher with a k-bit key against a brute force key search is about 2k, applications requiring block ciphers with k-bit keys should use hash functions with 2k-bit hash results. For example, an application using 128-bit key AES should use SHA-256, and an application using 256-bit key AES should use SHA-512.

Symmetric Protocols

Earlier, we said that a block cipher's encryption algorithm takes a key and an n-bit plaintext and produces an n-bit ciphertext. How do you use a block cipher to encrypt more than n bits? The answer is to wrap the block cipher primitive within a higher-level protocol. This higher-level protocol is called an encryption mode.

The Electronic Code Book (ECB) mode is perhaps the most intuitive way to use a block cipher to encrypt more than n bits of plaintext. Figure 6.7 depicts this process:

Figure 6.7. The ECB encryption mode

a. Pad the plaintext so that it is a multiple of n bits.

b. Split the resulting padded plaintext into n-bit chunks.

c. Encrypt each chunk independently.

Because the ECB mode is so intuitive, many applications use it to encrypt their data. Unfortunately, the ECB mode is also insecure; it leaks information about the encrypted plaintext. For example, recall that a single plaintext block always encrypts to the same ciphertext block (using a fixed key). This means that the message ABAB with a block cipher in ECB mode (where A and B represent n-bit plaintext blocks) encrypts to XYXY (where X and Y represent n-bit ciphertext blocks). An attacker looking at the ciphertext will learn that the first plaintext block is the same as the third and that the second is the same as the fourth. This gives the attacker information about the plaintext.

Another aspect of the ECB mode that the developer should be aware of is that n-bit blocks can be moved around within the message and still decrypt properly, although the message's meaning is changed. This is not a problem with ECB, though; it is a problem with the implementation. The encryption modes are tools to accomplish privacy, not integrity. Unfortunately, many applications mistakenly assume that encryption protocols will automatically prevent an attacker from tampering with encrypted messages. (More on this in the section "Common Problems.")

CBC

The Cipher Block Chaining (CBC) mode is a more secure way to encrypt long plaintexts. Figure 6.8 depicts this process:

Figure 6.8. The CBC encryption mode

a. Pad the plaintext so that it is a multiple of n bits.

b. Split the resulting padded plaintext into n-bit chunks.

c. Pick a random n-bit value called an initialization vector (IV).

d. XOR the first plaintext block with the IV.

e. Encrypt the resulting value using the block cipher.

f. The resultant ciphertext block is output and XORed with the next plaintext block.

g. Steps e and f are repeated until the end of the plaintext message is reached.

h. The message sent is both the random IV and the ciphertext message.

The important aspect of the CBC mode is that the same plaintext block or message always encrypts to different ciphertext blocks or messages (provided that a different IV is chosen for each encryption).

CTR

Counter (CTR) mode is another secure use of a block cipher to encrypt a long plaintext message. There are two general CTR mode constructions: randomized and stateful. The idea behind CTR mode is to use a block cipher as a stream cipher to generate a keystream. This keystream is XORed with the plaintext to produce the ciphertext. Both versions of CTR mode begin with an n-bit counter or seed i. Figure 6.9 depicts the process of a stateful CTR mode:

Figure 6.9. The stateful CTR mode

a. The plaintext message is broken into jn-bit blocks. The last block is padded so that it is a multiple of n bits.

b. Initialize i to some value (usually 0).

c. Encrypt i with a block cipher using key k.

d. XOR the output with the jth plaintext block.

e. Append the result to ciphertext results, and increment i and j.

f. Repeat steps c–e for all j blocks.

The initial counter i must be included with the ciphertext message or must be agreed on ahead of time by the sending and receiving parties. Of course, the sending and receiving parties should be the only ones who know the shared secret k.

The two versions of CTR mode differ only in how the value i is chosen. In the randomized version, a different random i is chosen for each message. In the stateful version, i is set to 0. With both versions every time a new block is encrypted, i is incremented. The value or state of i is maintained between plaintext messages. As with any stream cipher, care must be taken so that the keystream is not reused. In the stateful version, this is accomplished by ensuring that the counter i never wraps or by changing the key k before i wraps. In the randomized version, this is accomplished by changing the encryption key with enough frequency to ensure that the probability that the keystream will repeat is very low.

MAC

Privacy and integrity are two goals of applied cryptography. Encryption protocols are tools to accomplish privacy. We have noted that encryption does not accomplish integrity. This deficiency requires another class of protocols: message authentication codes (MACs). MACs are algorithms designed to protect the integrity of messages. If the transmissions are MACed, the receiver can detect whether a malicious attacker has modified a message. Most applications that require secure communications should use both an encryption protocol and a MAC.

A MAC consists of two parts: a tagging algorithm and a verification algorithm. The tagging algorithm attaches a MAC tag to a message, and the verification algorithm verifies a message's MAC tag. As with symmetric encryption modes, there are numerous MACs, some based on block ciphers and others on hash functions. The important point is that the chosen MAC needs to be resistant to tampering and sensitive to any modification to the message—cryptographically secure.


Asymmetric Cryptography

This section deals with asymmetric cryptography, cryptographic methods in which the encryption key is different from the decryption key. With this type of cryptography, the decryption process is not simply an inverse of the encryption process but a totally different mathematical transformation. Asymmetric cryptography is a very powerful technology because a key need not be shared between two communicating parties. This eliminates the concern of how a common key is shared.

Asymmetric Primitives

As with symmetric cryptography, asymmetric primitives are the building blocks for asymmetric cryptographic protocols and for secure asymmetric applications. Recall that although cryptographic primitives by themselves do not provide useful functionality, an understanding of these primitives is helpful in understanding the protocols

RSA

RSA is perhaps the most well-known asymmetric or public key technique. There are two families of RSA primitives: for encryption and for digital signatures. Although these two families are fundamentally the same (their underlying basic algorithms are identical), we distinguish between these two families because they accomplish different goals.

The details are not necessary for understanding the uses and importance of the RSA algorithms. Although you are encouraged to read this section, grasping the mathematics is not necessary. Many software libraries handle these details transparently, and most applications developers never have to work directly with the RSA primitives.

Before you can use the RSA primitives, you must generate public and private RSA keys. The process to generate these keys follows:

1. Select two large random prime numbers, and name them p and q.

2. Set the values n = pq and [image] = (p – 1)(q – 1).

3. Pick a random integer e greater than 1 and less than [image] so that the only common divisor between e and [image] is 1.

4. Derive the integer d between 1 and [image] so that ed _ 1 mod [image] (that is, the remainder of ed divided by [image] is 1).

5. The public key consists of the integers n and e, and the private key consists of the integers n and d.

When people refer to the size of an RSA key, they mean the length of the integer n in bits (that is, a 1,024-bit RSA key means an RSA key where n is 1,024 bits long). If you are astute, you may have noticed that the preceding procedures deal with integers. Likewise, the RSA encryption and signature primitives operate on integers. This, in and of itself, is not very useful. How often do you need to send or verify only integer data? Therefore, the higher-level protocols discussed in the next section handle the conversion between the data to be sent and an integer message, on which the RSA primitives operate.

To encrypt an integer m with the public key (n, e) resulting in the integer result c (where m and c are integers between 0 and n – 1), you compute c = me mod n.

To decrypt an integer c retrieving the integer m with the corresponding private key (n, d), you compute m = cd mod n.

The RSA signature and verification primitives are actually the encryption and decryption primitives in the reverse order. Therefore, to sign or produce a signature s of an integer m, both between 0 and n – 1, encrypt m with the private key (n, d): s = md mod n.

To verify the signature s, decrypt s with the public key (n, e): m = se mod n.

Because encryption and signature schemes are designed to meet different goals, and to avoid confusion, it is best to think of the encryption and signature families of RSA primitives as distinct. Additionally, although these primitives serve as the foundations for secure encryption and signature algorithms, by themselves they are insecure. Consequently, applications should not directly invoke the preceding RSA primitives. Rather, applications should use the RSA-based encryption and signature protocols discussed in the next section.

Discrete Logarithms

Another class of asymmetric primitives is based on the discrete logarithm and the Diffie-Hellman problems. These primitives work because of the difficulty computing the logarithm of elements in certain groups. (A group, as referenced here, is a set of elements related to each other in a mathematical way.)

The discrete logarithm problem is this: Given a prime p, a generator g of the multiplicative group Zp* and an element x in Zp*, find the least positive integer a so that x=ga mod p.

Now, if that made perfect sense to you, you can skip this explanation. If you responded with a "Huh?," read on. Okay, what does it mean in layman's terms? We will break down each portion:

1. A prime p in cryptographic terms is usually a very large number divisible by only 1 and p.

2. Recall that modulo, or mod, produces the remainder after an integer division operation (that is, 20 modulo 5 = 0, 17 modulo 5 = 2, and 2 modulo 5 = 2).

3. A generator g of the multiplicative group Zp* says that there is a generator (function) ga modulo p, where a may be in the range 0, 1, . . . p – 2, that produces all the elements in Zp*. The elements may not be produced in order, but all elements are produced when a takes on values through the entire range.

4. The multiplicative group Zp* is the set or group of positive numbers that is closed under multiplication with respect to the modulo of a prime p, or the set of positive numbers {1, 2, . . . p – 1}. Any member, when multiplied by another member, produces a product. This product modulo p falls within the set. For every element x in {1,2, . . . p – 1}, there is an inverse y in the set, so xy mod p = yx mod p = 1.

5. Find the least positive integer a so that x = ga mod p.

The discrete logarithm problem can be stated as follows: Given an integer a, you can easily compute x = ga, but no one knows how to efficiently compute a, given x and g. In fact, this is regarded as a very hard problem!

The Diffie-Hellman problem is this: Given a prime p, a generator g of Zp*, and elements ga mod p and gb mod p, find gab mod p.

Examining the problem from a different perspective, given only ga and gb (that is, you are not given a or b), it is very hard to compute gab. Of course, given ga and b (or given gb and a), it is easy to compute gab. The difficulty of computing gab given only ga and gb serves as the basis for many asymmetric cryptographic protocols.

For traditional discrete logarithms, the private key is an integer s between 1 and p – 2, and the public key is gs mod p. The prime p and generator g are not secret—they are known to all parties. When people refer to the size of a traditional discrete logarithm key, they mean the length of the prime p in bits (for example, a 1,024-bit discrete logarithm key means a key where p is 1,024 bits long).

Numerous discrete logarithm-based primitives exist. There are primitives for secret value derivation (so that two parties can compute a shared secret symmetric key), for digital signatures (so that an individual can electronically sign a message), and for signature verification (so that a recipient can verify a signature on a message). Each of these primitives includes many exponentiations (raising g or another element in Zp* to some power).

Elliptic Curve Discrete Logarithms

Elliptic curve–based cryptographic primitives are very similar to the discrete log primitives, except that the underlying mathematical group is an elliptic curve, instead of the positive integers modulo a prime number. Just as with the preceding group, you can define the discrete logarithm problem for elliptic curve groups: Given a cyclic subgroup G of an elliptic curve, a generator g of G, and an element x in G, find the least positive integer a so that x = ga.

For elliptic curve cryptography, the generator g and the elliptic curve are publicly known. The private key consists of an integer s between 1 and |G| – 1, and the public key consists of the curve point gs. When people refer to the size of an elliptic curve key, they mean the number of bits necessary to represent the subgroup G. For example, if G has about 2160 elements, the key size is 160 bits.

Generally speaking, computing the discrete logarithm for elliptic curve groups is more difficult than for Zp*. This means that you can use smaller elliptic curve groups and achieve the same effective level of security as with the larger Zp* groups. In practical terms, this translates into smaller key sizes and less network traffic. Elliptic curve implementations can also take up less space in dedicated hardware than traditional discrete logarithm or RSA cryptographic primitives. Therefore, the primary motivation for using elliptic curves is efficiency. Because efficiency is of greater concern with wireless systems than wired, this explains the interest in using elliptic curve algorithms with wireless systems.

Other Public Key Cryptographic Primitives

Other public key cryptographic primitives are in use or under development. Two that have drawn the interest of the wireless community are NTRU and XTR. Although relatively new, both have gained considerable attention throughout the cryptographic communities. The reason for bringing these to your attention is not to discuss further the details behind these two systems but to point out that the field is changing and which primitive will eventually become adopted as the standard for wireless systems remains to be seen. Further, as computing power and resources available on wireless devices increase, we are likely to see a progression to other, more secure algorithms in the future.

Asymmetric Protocols

Asymmetric protocols, like symmetric protocols, provide a method of utilizing asymmetric primitives to create cryptographic procedures to enable protected communications between participating parties. We shall explore four common asymmetric protocols that utilize the primitives as building blocks for useful functionality: Encryption, Digital Signatures, Key Establishment, and Certificates.

Encryption

To send a secret message, the sender encrypts the message with the recipient's public key, and the recipient decrypts the message with her private key. Simple, right? Not quite. The most common asymmetric encryption algorithm is RSA. However, recall that the RSA encryption primitive by itself is insecure. In particular, RSA works on integers. Most useful messages are noninteger, so conversion of the message to integer form must be done. The RSA encryption primitive must be "wrapped" in a more sophisticated and secure protocol. For RSA, such a protocol is the Optimal Asymmetric Encryption Padding (OAEP) mode.

To encrypt a message M with the OAEP mode, depicted in Figure 6.10, you do the following:

Figure 6.10. Encrypting with the RSA OAEP mode

1. Apply an OAEP-specific encoding to M to obtain an OAEP-encoded message (this step is critical).

2. Convert the encoded message to an integer m.

3. Apply the RSA encryption primitive to obtain the integer c.

4. Convert the integer c back to a noninteger ciphertext C.

To decrypt ciphertext C with the OAEP mode, depicted in Figure 6.11, you do the following:

Figure 6.11. Decrypting with the RSA OAEP mode

1. Convert C to an integer c.

2. Apply the RSA decryption primitive to obtain the integer m.

3. Convert m from an integer to an OAEP-encoded message.

4. Apply an OAEP-specific decoding operation to obtain the plaintext M.

We caution developers that many cryptographic libraries support older and insecure versions. Further, there is no guarantee that since the writing of this book another protocol has not superceded OAEP. Developers must ensure that they know which mode is being used in libraries they are using and that these libraries contain the latest and most secure protocols and modes.

Digital Signatures

Another big advantage of public key cryptosystems over private key cryptosystems is that public key cryptosystems enable parties to create digital signatures of electronic messages. A digital signature is analogous to a physical signature. Using the office complex case study, if Louis signs a message, NitroSoft (or anyone else) can examine the message and be reasonably assured that Louis actually signed it (and that the signature was not forged by Kathleen). The presence of the signature provides evidence that Louis saw and agreed to the contents of the message before it was signed. In this way, digital signatures can also provide nonrepudiation. (Recall that nonrepudiation means that, after signing a message, the signer cannot claim that he did not sign that message.)

As with the asymmetric encryption protocols, secure signature protocols build on top of the corresponding primitives. Digital signature schemes consist of two algorithms: a signature generation algorithm and a signature verification algorithm. Most applications that use digital signatures use digital signatures with an appendix. This means that the digital signature schemes attach a signature to the end of the signed message and require the signed message as input to the verification algorithm (some digital signature schemes reconstruct the original message from the signature). The most common digital signature algorithms are DSA (the U.S. Government's Digital Signature Algorithm), an elliptic curve version of DSA, and RSA-based signature schemes.

Key Establishment

Key establishment is the process of using asymmetric techniques to agree on a shared symmetric key that is then used to communicate securely. Although the previously discussed asymmetric encryption and digital signature protocols can be used to communicate securely over an untrusted network, asymmetric cryptosystems are typically much less efficient than symmetric cryptosystems. Consequently, almost all applications use a hybrid approach—a combination of symmetric techniques (for speed) and asymmetric techniques (to establish secure communications without any a priori shared secret).

There are two general classes of key establishment techniques: key transport protocols and key agreement protocols. In a key transport protocol, a session key is created and sent to the recipient. For example, Louis could create a session key, sign it, and then encrypt the key and the signature with NitroSoft's public key. Upon receipt, NitroSoft would decrypt the session key and signature, verify the signature (to ensure that the key came from Louis), and use the session key to communicate securely via a symmetric protocol.

In a key agreement protocol, both parties partake in the derivation of a shared session key. Many popular key agreement protocols are based on the discrete logarithm and the elliptic curve discrete logarithm problems. Here is a simple example:

a. Louis and NitroSoft publicly agree on a prime p and a generator g of Zp*.

b. Louis picks a non-negative integer a less than p – 1 and gives ga to NitroSoft.

c. NitroSoft also picks a non-negative integer b less than p – 1 and gives gb to Louis.

d. Louis computes (gb)a = gab and NitroSoft computes (ga)b = gab. The result, gab, becomes the shared secret.

Although this scheme is not perfect, it does present the basic ideas behind discrete logarithm-based key agreement protocols.

There are many desirable properties for key establishment protocols. One such property is perfect forward secrecy. This means that if an attacker compromises the private key of one of the individuals involved in a communication, the attacker should not be able to learn any of the prior session keys. The preceding example does not have perfect forward secrecy. If an attacker learns Louis's private key (n, a), she can compute (gb)a and obtain the symmetric key. An authenticated key establishment protocol is a key establishment protocol in which the parties can be assured that they performed the key establishment protocol with each other (and not an attacker).

Certificates

A discussion of asymmetric protocols should not neglect one significant problem— how do two parties know that they really have each other's public keys? The commonly accepted solution to this problem is to use certificates. A certificate is an attempt to correlate a user's public key with her real-world identity. At a minimum, a certificate contains a user's public key and identifying information about the user. The certificate is also signed by a trusted third party. This trusted third party is called a certificate authority (CA). By verifying the CA's signature on the user's certificate before communicating with her, you are somewhat assured that you are communicating with the user and not an impostor. A public key infrastructure (PKI) is a system with a certificate authority and a clearly defined way of obtaining, validating, and deleting certificates.


Common Problems

There tend to be two common problems with the use of cryptography in secure applications. First, some applications developers mistakenly believe that simply incorporating strong cryptography into their applications makes them secure. Second, some applications developers invent their own (proprietary) cryptographic algorithms. This section addresses both these problems.

Cryptography by Itself

Designing a secure application is about making decisions, and these decisions often affect how the application uses cryptography. If an application uses cryptography incorrectly (for example, using an encryption algorithm when it should use a message authentication algorithm), it will probably be insecure. The design decisions of applications developers also affect whether there will be holes in an application's design that allow an attacker to attack the application itself (instead of the cryptography). An example of a design flaw would be an e-mail encryption program that uses strong cryptography to encrypt a user's e-mail but stores the user's pass phrase unencrypted on the user's disk. Another common mistake is to assume that an attacker will not reverse-engineer an application to extract its embedded cryptographic keys or learn the details behind its proprietary cryptographic protocol. An example of this is the copy protection schemes employed by game manufacturers. As soon as a new game or protection scheme is released (and sometimes sooner), there is a crack, or some site has an unprotected version available for download.

The point is that although cryptography is a powerful tool, the designer of an application must not consider cryptography a silver bullet. Application security is more than just cryptography and must be designed in from the beginning.

Proprietary Cryptographic Protocols

A common rule-of-thumb phrase in the security industry is Never roll your own cryptography (unless, of course, you are a cryptographer, and even then, never use what you have designed until others have thoroughly evaluated it). Although this now trite expression is laughed off, it is fundamentally true.

Companies invent their own proprietary algorithms for several reasons. Some believe that cryptography is not that difficult or that they can invent revolutionary new protocols more secure than existing solutions. Others believe that an attacker will have a more difficult time breaking the company's secret protocols than published, well-known, academically accepted protocols.

Although there is some truth to both these beliefs, they can be quite dangerous. (Unfortunately, it is the end user who is often affected and not the developers.) To address these beliefs, we would like developers to consider the following.

Companies and developers who create their own cryptographic protocols seldom have seasoned cryptographers review their designs. This is especially true when companies keep their protocols secret. Consequently, unless a company employs its own world-class cryptographers, its proprietary protocols may not be as secure as it believes. Likewise, although the underlying cryptographic primitive or protocol design may be secure, the implementation may be flawed, negating any security or advantage in using the proprietary protocol.

A well-known mathematician/cryptographer named Kerckhoff said something to the effect that if an algorithm is secure against an attacker who does know the inner workings of that algorithm, that algorithm will be secure against an attacker who does not know the inner workings of that algorithm. We further observe that one of the best ways to understand the security of an algorithm is to have seasoned cryptographers try to break it (or try to prove something about the security of that algorithm with respect to a trusted primitive). If, after a reasonable effort, the world's best public cryptographers cannot break that algorithm, you can have confidence that the algorithm is secure.

With this in mind, if a publicly accepted algorithm is secure against the world's best public cryptographers, obviously, that algorithm should be secure against the casual attacker. Furthermore, the preceding observations suggest that application developers should choose older, more analyzed algorithms over flashy new algorithms that have yet to be proven. This is provided that the older algorithms are secure, given your situation and intended use.

Despite the preceding advice (which is not being presented here for the first time by any means), the development industry is still infused with insecure cryptographic algorithms. As you might expect, people eventually get around to breaking these algorithms. The heavily publicized flaw with 802.11's Wired Equivalent Privacy (WEP) protocol is an example of why the preceding advice should be heeded. Some of the flaws with WEP are classic, and almost any experienced cryptographer could have identified and avoided them. If the authors of the 802.11 Specification had properly involved cryptographers during the design of WEP, these issues could have been identified and resolved before the specification was implemented and used commercially.

Common Misuses

In addition to creating their own protocols, one of the most common mistakes people make when designing secure applications is not to use cryptographic protocols the way they were intended. This might be analogous to not following the directions included with a house smoke detector or burglar alarm—the smoke detector will not be of much use if the batteries are not replaced and the burglar alarm is not connected properly to the siren and phone line. The same thing is true for cryptography— cryptographic protocols come with rules that must be followed.

The following is a list of common misuses of cryptographic protocols. Although not exhaustive, it will help wireless and application developers understand and avoid some of the most common pitfalls.

Key Generation

When we first introduced encryption, we said that an encryption protocol consists of two parts: an encryption algorithm and a decryption algorithm. That is not completely true. It actually consists of three parts: an encryption algorithm, a decryption algorithm, and a key generation algorithm. The same can be said for many other protocols. For example, a message authentication code actually consists of a tagging algorithm, a verification algorithm, and a key generation algorithm.

Although we did not mention the key generation algorithm earlier, the key generation algorithm is among the most critical portions of a secure cryptographic protocol. To see this, recall that one way for an attacker to break an encryption protocol is to find the decryption key. In the symmetric setting, if a k-bit encryption key was chosen randomly, the attacker might have to guess 2k keys before she stumbles on the right one. Thus, in the symmetric setting, we argued that the strength of a secure encryption algorithm correlates roughly to the size of that algorithm's encryption key.

Unfortunately, that is true only if the encryption key was generated correctly or randomly. What if the encryption key was not generated randomly? That is, what if certain encryption keys are more probable than others? For example, what if the encryption key depends on the user (perhaps as a function of the user's social security number or birthday)? What if the encryption key consists of a number of zeros followed by a few random bits? In both cases, an attacker would be able to guess the encryption key in far fewer than 2k tries. This means that although an encryption algorithm with randomly generated keys might be secure (because an attacker can't possibly make 2k guesses), the algorithm may not be secure in practice (because the user's application doesn't properly generate random keys). Developers and users should be aware that if anything other than random numbers is used, the security of the encryption is adversely affected.

Randomization

Key generation algorithms are not the only algorithms that require random numbers; many cryptographic protocols use random numbers to circumvent certain attacks. For example, the CBC and stateless CTR encryption modes rely on random numbers to prevent a single plaintext from always encrypting to the same ciphertext. To use these protocols properly, developers must ensure that applications correctly supply the protocols with random numbers.

Any algorithm for generating random numbers is only a pseudo-random number generator (PRNG) because random behavior cannot, by definition, be captured by an algorithm. Worse, many of the PRNGs provided as library function calls are not random at all. They are quite predictable. Developers should ensure that, if a random number is called for, the source of this number is known and its randomness is acceptable for the usage.

Key Management

As its name implies, key management is concerned with the way applications handle cryptographic keys. Key management addresses issues such as key generation, key agreement, and key lifecycle. Each cryptographic protocol has different requirements for the way its keys are handled.

There are some general (though often ignored) principles for key management. One principle is that the same cryptographic key should not be used for multiple purposes. For example, you should not use the same key pair for the RSA encryption primitives as you use for the RSA signature primitives. Similarly, the same symmetric key should not be used for symmetric encryption and symmetric message authentication code. Multiple usages may inadvertently leak information useful to an attacker.

A similar principle is that multiple parties should not share the same key. Although this principle may seem intuitive (because the more parties that know a key, the more likely it is for an attacker to learn the key), many modern applications (including most WEP installations) still distribute identical keys to multiple parties.

Another often ignored principle is that keys should be changed over time. Regularly changing keys limits an attacker's ability to learn about the key, by placing a time period on a key's usability. For example if a key can be learned by capturing a certain number of WEP packets, the key should be changed before sending that many packets. With poorly implemented schemes, this period of time may be very short indeed, rendering the encryption practically useless.

Keystream Reuse

When introducing stream ciphers, we emphasized that you should be extremely careful not to reuse a keystream. Although most people are aware of this restriction, numerous applications still reuse a keystream. If an application reuses a keystream, an attacker could learn information about the plaintexts encrypted with the reused portions of the keystream. As a visible example of this problem in common applications, the 802.11 WEP Specification does not properly prevent keystream reuse.

Encryption versus Authentication

When most people think about cryptography, they think about encryption. Although there may be an historical basis for correlation cryptography with encryption, this is no longer the case. Modern cryptography is concerned with more than just encryption; it is concerned with other concepts as well (such as integrity and authentication).

This bias of regarding encryption as synonymous with cryptography causes many people to use encryption when they should use some other cryptographic protocol. For example, many people make statements like this: "We'll encrypt this message. If the recipient of the encrypted message can decrypt it, the recipient will know that the message really came from us." Unfortunately, this is not necessarily correct.

The problem comes down to following a protocol's directions—the directions for encryption protocols say that the protocols are tools to accomplish privacy. The directions for authentication protocols say that they are tools to accomplish authenticity, and the directions for integrity protocols say that they are tools to accomplish integrity. By misusing encryption to provide message integrity, application developers can unintentionally open their applications to attack. This problem is exemplified in the 802.11 WEP Specification: Because the WEP protocol does not include any formal message integrity code, an attacker can make controlled, precise, and undetectable modifications to WEP-encrypted packets.

The Man-in-the-Middle Attack

When introducing the asymmetric cryptographic protocols, we mentioned the motivation for certificates: Certificates enable a user to verify that her copy of someone's public key is legitimate (not a public key created by an attacker). Unfortunately, many applications fail to verify properly the authenticity of other entities' public keys. When this happens, an attacker can mount a man-in-the-middle attack. In the office complex case study, Kathleen can pretend to be Louis to NitroSoft and NitroSoft to Louis. In this way, she can undetectably listen to and modify the communications between Louis and NitroSoft.

Buffers and Information Leakage

One final area, often overlooked by developers, is the handling of the plaintext information after it has been encrypted. If plaintext information is left in memory or on disk, it may be accessible to an attacker, either directly through physical access to the user's machine or by leakage of remnant information in buffers used as temporary storage during the encryption or decryption process. If these memory areas are not cleared after processing the plaintext information, another process may be able to access this information and break the application's security without ever looking at the extremely secure encryption protecting the information being sent over the network.


Choices

The developer of a secure application is often faced with many important decisions. Not least among these is which cryptographic algorithms the application should use. For example, which block cipher should the application use, DES or AES? Which encryption mode, CBC or CTR? Which message authentication code, CBC-MAC or HMAC? Which asymmetric algorithm, RSA, elliptic curve, NTRU, or something else? Although prescribing a precise formula for picking a cryptographic algorithm (protocol or primitive) is impossible, this section informs the developer of the available options so that she can make an educated decision.

When selecting a cryptographic algorithm, the developer must take several aspects of that algorithm into consideration:

· The algorithm's intended purpose

· The algorithm's performance

· The algorithm's effectiveness at accomplishing its intended purpose

· External regulations (for example, export laws or existing patents)

We have already discussed the intended purpose of various algorithms and protocols in previous sections; external regulations we leave to the more politically inclined. Therefore, in the following sections we will provide some additional information on performance and effectiveness.

Performance

Different applications have different performance requirements. The presence of these various performance requirements means that certain algorithms are desirable in different situations. For example, some algorithms are incredibly fast in hardware but slow in software (and vice versa). Other algorithms are fast on certain processors (for example, processors with integer multipliers) but slow on others. Some encryption algorithms can change keys quickly but have slow encryption speeds (such algorithms might be suitable for high-speed cryptographic routers that must simultaneously handle many secure channels).

Some algorithms are also faster in one direction than another. For example, the RSA signature generation algorithm is slow, but the RSA signature verification algorithm is incredibly fast, as you can see in Table 6.2. This table is taken from the article "Performance Comparisons of Public-Key Cryptosystems," by M.J. Weiner, in CryptoBytes, 4(1), 1998. The performance measurements are milliseconds on a 200MHZ Pentium Pro.

In addition to speed, there are space considerations. Elliptic curve implementations can take up less space in dedicated hardware and are less network-intensive (transmit fewer bits) than RSA. These observations mean that it would be incorrect to argue that one scheme is faster than another. Applications developers must thoroughly understand how their application will use cryptography before deciding on the algorithm best suited for the application.

Effectiveness

The effectiveness or security of a cryptographic algorithm is a measure of that algorithm's resistance to attacks. The more secure an algorithm is, the more effective it will be at preventing an attacker from breaking the message. Unfortunately, quantifying an algorithm's security is a subjective process. There are several reasons for this. First, effectiveness means different things to different organizations and applications. This is exemplified by the fact that financial institution or governmental security requirements are usually much greater than those of most individuals. Thus, different applications will likely have different definitions of security and effectiveness. (For example, a government organization might require 2,048-bit RSA keys, whereas a normal user might find 1,024-bit RSA keys quite effective.)

Table 6.2. Performance Comparisons of Asymmetric Key Protocols

Operation

1,024-Bit RSA

1,024-Bit DSA

168-Bit ECDSA

Signature generation

43

7

5

Signature verification

0.6

27

19

Key generation

1,110

7

7

Another problem with measuring the security or effectiveness of an algorithm is that an algorithm's effectiveness typically decreases over time. For example, as the speed of hardware increases (and the price of hardware decreases), the time (and money) necessary to run a single attack algorithm will decrease. If brute-forcing a 56-bit DES key today takes two days, then, after the speed of computer hardware doubles, it should take only one day, using equivalently priced hardware. Furthermore, new advances in cryptanalysis may yield more efficient attacks. These factors must be considered in evaluating a potential cryptographic solution against the data protection requirements: Some applications require that their information remain protected for years (such as wills and contracts), whereas other applications require that their information remain protected for only a short time (such as instructions for a negotiation occurring that afternoon).

Table 6.3 presents the suggested key length for a specific class of primitives. This table is taken from the article "Selecting Cryptographic Key Sizes," by A.K. Lenstra and E.R. Verheul, in The Journal of Cryptology, 2001. Recall that the key length of an algorithm is one measure of that algorithm's security. The primary assumption underlying the data in Table 6.3 is that DES offered an appropriate level of security in 1982. We recommend consulting the source of Table 6.3 for different baselines and the rate with which hardware speeds and cryptanalytic attacks will improve. We want to state that Table 6.3 does not provide our suggested key lengths for the differing algorithms. It is simply meant as a comparison between different algorithms. As previously stated, the security required is dependent on the application and environment in which it must operate.

Table 6.3. Sample Minimal Acceptable Key Lengths (in Bits) per Year

Year

Symmetric Key Size

Hash Size

RSA and TDL Key Size

RSA and TDL Key Size*

Elliptic Curve Key Size

2000

70

140

952

704

132

2002

72

144

1,028

768

139

2004

73

146

1,108

832

143

2006

75

150

1,191

896

148

2008

76

152

1,279

960

155

2010

78

156

1,369

1,056

160

2020

86

172

1,881

1,472

188

2030

93

186

2,493

2,016

215

Decision Trade-Offs

Application developers are often unable to choose an algorithm (or key size) simply for its security. Rather, application developers often must accept a compromise between security and performance. Unfortunately, what that compromise should be is often unclear (especially considering that it is impossible to ascertain fully the security of most cryptographic algorithms).

Of particular concern to most wireless developers is which asymmetric system to use (RSA, elliptic curves, NTRU, XTR). This is an extremely difficult decision, and one which the cryptographic community appears to be debating still. If the security predictions in Table 6.3 are accurate, the performance observations in the preceding subsection suggest that certificate-based software application (applications that do many certificate verifications) should use RSA and that most other applications (non-certificate-based applications and hardware implementations) should use elliptic curves. Unfortunately, not everyone agrees with the results in Table 6.3.

We have suggested that, when given the choice, you should choose older, more established cryptosystems over newer and flashier cryptosystems. This is because cryptographers tend to understand the security properties of older cryptosystems more than they do newer cryptosystems. This argument holds for the RSA versus elliptic curves debate as well. Because the RSA cryptosystem is older than the elliptic curve cryptosystem, some cryptographers believe that it would be dangerous to assume that elliptic curves will not succumb to future cryptanalytic progress. That is, some cryptographers believe that clever researchers will someday find a flaw with elliptic curve–based cryptosystems that allows an attacker to efficiently break any elliptic curve–based cryptosystem. Other cryptographers strongly disagree. Although we argue again that predicting the future is impossible, wireless application developers should be aware of this debate and remain abreast of developments involving cryptosystems of interest.


Key Points

When selecting keys, make sure that they are generated randomly. The strength of the algorithm is dependent on random keys. Do not assume that random number functions produce good random numbers. Do your homework before selecting a PRNG or pseudo-random number generator. Perform proper key management. Do not do the following:

· Use the same cryptographic key for multiple purposes.

· Share the same key with multiple parties.

· Use the same key for an extended time or past its key life.

· Reuse the keystream when using stream ciphers.

We close this chapter by reemphasizing the major points covered. Use cryptographic primitives and protocols for their designed purpose, and ensure that you follow any specific directions or qualifiers. Unless you are a cryptographer, do not "roll" your own cryptography. Encryption is not the same as authentication or integrity. Cryptographic techniques may be used to accomplish all three, but they are distinct activities. Finally, cryptography is a tool to assist in building secure applications and systems, not a security solution on its own.


Chapter 7. COTS

The last time somebody said, "I find I can write much better with a word processor," I replied, "They used to say the same thing about drugs."

—Roy Blount Jr.

Commercial off-the-shelf (COTS) products present another trap into which we sometimes fall when looking for security. COTS products offer a false sense of security in some cases. They should be used when necessary and can offer a partial security solution, but they should be understood first and used with great care. This chapter investigates some popular wireless industry COTS products and examines how they can fit in to protecting a wireless application or system.


COTS versus Custom Software

COTS software is commercial off-the-shelf software, such as Windows XP or Quicken 200X. COTS software includes commercially produced and supported software products that enhance the productivity of electronic computing devices. Generally, they are well tested, documented, and supported products that provide the advertised functionality. It is assumed that they provide the necessary security and privacy features associated with protecting the data that the application will process. This is usually not the case. In the rush to meet marketing and delivery dates, security is the first to be sacrificed. At a recent trade show, one software vendor was heard to say, "We think the market will be willing to forgo the security concerns to be able to utilize the enhanced functionality." This may be the case, but you can bet that the marketing materials do not highlight the fact that the product does not provide the users or their data with privacy or confidentiality.

We are not saying that all COTS products have this flaw. The point is that knowing what you are not getting is just as important as knowing what you are getting. Do not assume that a product does something unless you are explicitly told it does. You must verify what is and is not being done by products used with your system.

Custom Software

Custom software is proprietary software that is built internally, or contracted for, and usually integrates COTS software into a business's computer system to accomplish a business objective. Custom software is commonly used in linking a legacy inventory control system or a CRM system to a Web-enabled front end. It enables a traveling sales or marketing team to access current pricing information on a legacy system to be accessed via a Web or custom interface.

Custom software is usually requested to meet a specific functional or utility deficiency among COTS products or between COTS and legacy systems. Sometimes they are contracted to patch or fix security vulnerabilities or weaknesses that arise when legacy systems originally accessible only via closed internal networks become accessible to the outside world via Internet or wireless connections.

The potential for security weaknesses increases as the number of components designed to work independently under specific operating assumptions are integrated into larger, more complex systems. Software programs or components are usually tested for functionality, not security. As mentioned in earlier chapters, the exploitation of a component is usually accomplished by getting the software to do something it was not intended to do. Normally, from both a time and cost perspective, security testing is not performed unless it is specifically required or the software is destined for use in a security-critical area. Again, in these situations, the initial requirements often specify that this type of testing must be performed.

For example, when a software vulnerability was identified in a certain company, the developer was brought in, and the vulnerability was described. The developer's response was, "We knew about the issue, but we could not think of a situation in which users would encounter the circumstances that would allow that vulnerability to be exploited. And at the time, if they did, it would not grant them access to anything that they already did not have access to through some other means."

Here is how it became an issue. This software was integrated with other software and systems to provide Internet-based access for the entire company. Systems and services assumed that this piece of software was providing access control and authentication, so these systems blindly accepted requests coming from this process, further assuming that they were authorized. A network-based attack against this piece of software identified the vulnerability, and over time an exploitation was devised that allowed a network-based attack to gain access to the company's entire set of backend servers. It was not totally the fault of the software, however. Logs being generated had identified that someone was attempting to exploit the vulnerability, but the logs were not routinely examined.

You can learn several lessons from this brief example:

· Software will not always be used in the environment to which it was originally developed.

· You should not rely on other systems or services to provide security for you, unless you have verified that they are doing so in all cases.

· Logs are good as a security protection measure only if someone knowledgeable, who can identify potential attacks, examines them on a routine basis.

We will now look at several technologies being used, or contemplated, to provide add-on COTS and custom security solutions to networks, both wired and wireless.


Virtual Private Network (VPN)

A VPN is a network of two or more computers, or computer systems, linked together over the public network in a manner that virtually creates a private network. Figure 7.1 shows how the network can be connected, with the lines between networks indicating two VPNs: one between Computer A and the PDA and one between Computer B and Server 2.

Figure 7.1. An example of VPNs

Figure 7.2 shows how the network is logically connected. When implemented correctly, these VPNs provide the security of a direct private network connection, with the cost saving and scalability of using public Internet connectivity. The key word in the preceding sentence is when. Just because you have a VPN system in place does not mean that your communications and network are safe.

Figure 7.2. VPN logical connections

A private network used to mean a network with no external connectivity, only accessible by direct, controlled, co-located connectivity, as depicted in Figure 7.3. To expand this type of network to multiple locations required the use of dial-up or dedicated/leased lines between locations, and in security-sensitive deployments, the use of some form of link encryption over these leased or dial-up lines. This model was expensive to maintain and not very scalable (see Figure 7.4).

Figure 7.3. A private network with no external connections

Figure 7.4. A private network with external connections

To be able to utilize the cost savings and scalability of the Internet or public networks, security professionals began to create VPNs via the combined use of encryption, authentication, and mechanisms for obfuscating information about the private network topology from the public network. The benefit of this idea is that by utilizing a properly implemented VPN, you have access to the entire private network from any location, as if you were physically co-located and connected to the network.

The disadvantages are that the Internet cannot provide the level of security, bandwidth, versatility, and reliability available on a private network. However, as we have discussed in other chapters, the increased utility of being able to access the private network from outside and varying locations outweighs the limitations currently imposed by the use of a VPN.

Three basic types of VPN products are on the market today: hardware-based, firewall-based, and software-based.

Hardware-Based VPNs

Most hardware-based VPN systems are encrypting routers. They are generally secure and easy to implement. Of all VPN systems, they tend to provide the highest network throughput because they are functionally specific and processor resources are concentrated on performing the routing and encryption tasks. Looking at Figure 7.5, you will notice that it is essentially the same layout as Figure 7.4, except that it utilizes the public Internet for between-location connectivity.

Figure 7.5. A hardware-based VPN

However, hardware-based VPNs are not as flexible as software-based systems, should changes be required because of upgrades or modifications in the backend network. Certain complete hardware VPN packages offer software-only clients for remote installation and incorporate access control features more traditionally managed by firewalls or other perimeter security devices. As with many additional features, they come with security concerns. That the VPN is remotely installable implies that it is remotely administrable, and this raises questions about the authentication and security mechanisms in place on this device.

Firewall-Based VPNs

Firewall-based VPNs leverage the firewall's security mechanisms to provide VPN functionality (see Figure 7.6). These VPNs use the firewall to restrict access to the internal network, perform address translation and authentication, and provide real-time alarm and logging capability. Most commercial firewalls strip out potentially vulnerable or unnecessary services (called hardening), increasing their security posture. Many resources are available for ensuring the integrity and security of firewalls. Network administrators should utilize these resources to ensure that a firewall is performing the tasks anticipated so that the additional security provided by a VPN is not circumvented by some other vulnerability in the firewall.

Figure 7.6. A firewall-based VPN

The drawback is that VPN services place additional processing responsibility on the firewall, and if the firewall is already heavily utilized, performance can be affected. Some vendors are offering hardware-based encryption co-processors or accelerators to increase the efficiency of firewall-based VPNs.

Software-Based VPNs

Software-based VPNs are ideally suited for situations in which the client and server sides are not necessarily controlled by the same administrative organization (see Figure 7.7). They are also beneficial when a variety of network hardware, such as firewalls and routers, is implemented within the same organization. This is because they provide VPN services above the hardware level and provide the greatest flexibility in how network traffic is managed. Many software-based VPN products provide for tunneling (more on this in the next section) based on address or protocol, whereas firewall and hardware-based VPN products tunnel all traffic.

Figure 7.7. A software-based VPN

Software-based VPN systems are generally harder to administrate than hardware-based or firewall-based VPN solutions. Software-based solutions generally require familiarity with the host OS, the application, the network architecture, and the security mechanisms being employed. With the preceding combination there is greater risk that the software will not be implemented or configured properly, opening vulnerabilities that may be exploitable. Software-based solutions may be vulnerable to weaknesses at lower network layers or in the hardware itself. The best software security solution does no good if there is a way to bypass it altogether at the hardware level. Implantation of individual components of the VPN solution may have vulnerabilities that expose the entire system to risk, such as vulnerabilities in the way authentication is achieved or weakness in the session key or encryption algorithm. Every component must function properly and securely for the overall system to be reliable and secure.

The trend in the VPN market is to combine the best of the three VPN solutions into more useful, functional, and flexible products. As this trend continues, the lines between these three basic VPN systems will blur and eventually may disappear altogether. The proposed implementation of IPSec (discussed in a later section) is likely to hasten the transition to a more integrated VPN solution.


Tunneling

Tunneling is the concept of wrapping non-TCP/IP-compliant protocols within a protocol that can transit the public Internet. Two major tunneling protocols are prevalent today: PPTP and L2TP. A third is on the horizon, IPSec, which we will soon discuss.

The Seven-Layer OSI Model

Before continuing our discussion on tunneling, it is worth reviewing some networking basics. Figure 7.8 shows the standard seven-layer OSI (Open System Interconnection) network reference model, which we will briefly describe.

Figure 7.8. The seven-layer OSI network reference model

Layer 1—The Physical Layer

The physical layer (L1) is primarily concerned with transmitting raw data bits over communications medium and recovering the same raw data bits on the receiving side. This is where the determination is made of what constitutes a 1 bit and what constitutes a 0 bit. Here are examples of the communication media that can be used:

· A physical wire carrying voltage, current, or frequency changes

· A light carrying frequency changes or pulses

· Sound or radio waves with varying frequencies

Layer 2—The Data Link Layer

The data link layer (L2) manages link setup, data exchange, and link termination. L2 is concerned with taking the raw transmission and transforming it into what appears to be an error-free transmission to the network layer. Recall that L1 merely takes bits it is given and sends them over the communications media; it has no concept of structure or the meaning of the bits. L2 frames groups of bits by adding bit patterns to the start and end of a group. This group is called a physical layer service data unit, but more commonly a frame. Specialized frames report errors, acknowledgments, and the overhead to manage a session.

Layer 3—The Network Layer

The network layer (L3) controls the interconnectivity of network computers, nodes, switches, and routers. It determines the characteristics of the computer, node, and router interface and how L3 datagrams or packets are routed within the network. L3 ensures that all packets are correctly received at their destination and determines the route the packets will take in traversing the network. This includes translating logical network addresses and names into their physical equivalents.

Layer 4—The Transport Layer

The transport layer (L4) manages the flow of data between hosts across a network. This is accomplished by splitting long data streams into smaller chunks that fit within the maximum packet size for the networking medium being used. These chunks are then encapsulated with header and ending frames, which provide sequencing and error detection/correction capabilities. L4 is a source-to-destination or end-to-end layer and is responsible for ensuring successful transmissions, including retransmission if packets arrive with errors.

Layer 5—The Session Layer

The session layer (L5) is the user's interface into the network. L5 manages session setup, data exchanges, and session termination. It provides synchronization services between tasks at each end of the session, allowing for resumption of the session at the point where an error occurred rather than requiring the entire session to be retransmitted. L5 also performs any overhead necessary to maintain the session during periods of inactivity.

Layer 6—The Presentation Layer

The presentation layer (L6) performs any data-format translation for the networked communications. It takes data in the format the application understands and translates it into a generic format that can be transmitted over the network. Data compression may also occur at this time. Received data is translated from the generic format to the format the application understands.

Layer 7—The Application Layer

The application layer (L7) allows access to network services such as networked file transfer, messaging, and remote procedure calls that support applications directly. This layer also controls general network access and portioning of tasks across the network and provides network error and status information for applications.

PPTP

The Point-to-Point-Tunneling Protocol (PPTP) is a networking technology that supports multiprotocol virtual private networks. This allows your private network to utilize IP, IPX, and NetBEUI and provides access to a wide variety of existing LAN infrastructures. PPTP is supported in nearly all the current Microsoft products because Microsoft was one of the original members of the consortium defining the standard, including specifications for Linux and other platforms.

In an effort to make PPTP a complete VPN solution, Microsoft markets PPTP with other components to provide the authentication and encryption required for a VPN. The authentication is provided in various ways, depending on the platform. In Windows NT, this is done via the Remote Access Service (RAS): the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP).

RAS utilizes a shared secret between the RAS client and the RAS server. This shared secret is in the form of a user-supplied password at the client, which is then used to derive a MD4 hash. The stored password in the Windows NT security database at the server is used to compute the same MD4 hash. Although this solves the problem of key distribution, it leaves the system vulnerable to cryptographic attacks to identify the hash value. In fact, in 1998, Counterpane Systems released a statement that five major security flaws existed with Microsoft's implementation of PPTP and several other attacks were identified that would compromise the security of the VPN. (See Chapter 6 , "Cryptography," for more on cryptographic attacks .)

The important point to remember is that even though a standard or defined protocol is used, it is the implementation that truly provides the security. If the implementation is flawed, the security profile is compromised. Protocols or standards sometimes receive bad press when actually the particular implementation is to blame. Even when the implementation is performed by smart, knowledgeable groups, there can still be problems.

L2TP

The Layer Two Tunneling Protocol (L2TP), an extension to the PPP, enables ISPs to operate VPNs. PPP defines a standard for encapsulation of multiprotocol packets over L2 links, and its use in L2TP provides the flexibility to carry any routed data protocol. L2TP merges the best features of two other tunneling protocols: PTPP from Microsoft and L2F from Cisco Systems. As the name implies, the tunneling occurs at the network layer (L3), or at the data link layer.

L2TP is made up of two main components: the L2TP Access Concentrator (LAC) and the L2TP Network Server (LNS). The LAC is the device that terminates a connection or link and provides a means of access to the physical layer for communications. The LAC is also known as the network access server in Layer 2 Forwarding (L2F), a predecessor to L2TP. The LNS is the device that terminates the PPP data stream. The LNS can also be used to authenticate the data stream. It can have only a single LAN or WAN interface but can terminate calls arriving via any LAC's interface. For example, async serial, ISDN, PPP over ATM, or PPP over Frame Relay. The LNS is also known as the Home Gateway (HGW) in L2F terminology.

As with PPTP, L2TP requires the use of additional components to provide the encryption and user authentication for VPN security. Likewise, L2TP is susceptible to the same vulnerabilities as PPTP. However, under L2TP the tunneling is performed at L2, so this provides greater flexibility in what encryption protocols are used.


IPSec

IPSec is an attempt to bring together several security technologies into a complete solution to provide confidentiality, integrity, and authenticity. After your reading the preceding chapter, these three functions should indicate to you that IPSec is an encryption-dependent solution. In fact, IPSec utilizes the following encryption technologies to achieve its goals:

· The Diffie-Hellman key exchange is used to derive key material between peers on a public network.

· PKI (public key infrastructure) is used for signing the Diffie-Hellman exchanges to guarantee the identity of the parties and avoid a man-in-the-middle attack.

· Data encryption algorithms such as Advanced Encryption Standard (AES) are used to compute encrypted equivalents for data.

· Key hash algorithms such as HMAC are used in combination with traditional hash algorithms such as MD5 or SHA to provide packet authentication.

· Digital certificates signed by a certificate authority are used for user identification.

To implement IPSec, a new set of headers must be added to IP datagrams. The new headers are placed after the IP header and before the L4 protocol. Although IPSec goes a long way toward solving the current challenges facing the Internet, it falls short in the realm of wireless networks, at least until wireless devices are built that are compatible with IPSec.


SmartCards

SmartCards are small plastic cards about the size of a credit card. In some cases, they are credit cards, with an embedded microchip that can be loaded with data and applications. These applications can be used for telephone calling, electronic cash payments, storing personal medical history and data, verifying identity, tracking purchases, and providing automatic discounts for volume or loyalty purchases.

The physical hardware for making the cards and the devices that can read these cards is currently produced by three principal companies: Bull, Gemplus, and Schlumberger. The software that runs these cards is based on a restricted subset of Java. The operating system to support this language is the Java Virtual Machine (JVM). The OS provides authentication and authorization for loading new applets, managing the card's applets, and maintaining the card's integrity. The language is referred to as JavaCard. The card manufacturer or other software vendor contracted to develop the particular Java program or applet may write the applications.

SmartCards provide a mechanism by which data storage and processing can be performed in a secure environment kept physically on the person on whose behalf this processing is being performed. SmartCards allow personal information to be stored and provided to authorized services via insecure or untrusted hardware and networks, used as the transmission medium. This capability is accomplished by providing authentication and encryption capability on the card itself so that no personal information leaves the card bound for unauthenticated entities, or in unencrypted form. If you are purchasing or integrating an existing SmartCard implementation into your wireless network or device, you are trusting that the SmartCard is functioning as advertised.

By this point in the book, you should be asking yourself, how do we know that the OS and applets were implemented properly? Aren't SmartCard developers subject to the same potential errors and omissions as OS or application developers? How is it guaranteed that a malicious applet is not loaded onto the card? How do I know that the encryption is done properly? How do I know that the keys are generated and stored in an appropriate manner? What if someone steals my SmartCard—can she get my private information?

This is not a book on SmartCard security, so we will not go into detail on these issues. Typically, the cards that reach consumers are free from errors and provide the services specified. However, we bring them up here to reinforce the following points:

· Don't trust that others, even those whose primary purpose is security, are providing capability or services, just because it seems logical that they are.

· Knowing what they are not providing is as important as knowing what they are.

· Just because someone or something should be doing something does not mean that they are.


Biometric Authentication

Biometric authentication is the science of authenticating someone by analyzing biological data, primarily human bodily characteristics such as fingerprints, retinal and iris patterns, voice patterns, facial features, signature, typing characteristics, and DNA. This form of authentication requires that the known result of the sampled biometric characteristic be stored on a central server or on a SmartCard, which is presented with the sample for comparison. Let us emphasize that we are not talking about biometric identification, which is a much more complicated problem of taking a biometric sample and comparing it against a large database of samples to look for a match. Biometric authentication means taking a sample and comparing it against a known target and producing a yea or nay response.

In considering a biometric authentication solution, you should examine several factors:

· Perceived ease of use

· Acceptable transaction time

· Contingency measures for errors

· Location of actual authentication

· Gathering, verification, and storage of initial information

· Compatibility and connectivity issues

Other usability issues surround the use of biometric authentication, from user willingness to be subjected to sampling, based on health concerns (as in a laser-based retinal scan, for example), to users not wanting their fingerprint or DNA information stored on a central server that may be exploited by the government or a corporation for some other purpose. There are ways of potentially alleviating these privacy fears, such as encrypting the information as the sample is made and storing the encrypted form so that the original information cannot be retrieved. (Privacy issues are discussed in greater detail in Chapter 8 , "Privacy.")

Potential security vulnerabilities also must be overcome, such as the following:

· The robustness of the user interface

· The security of the interface between the authentication device and the host system

· The security of the third-party transportation network

· The security of the authentication server and application

· The security of the host device

· The security of the database

· The integrity of the biometric device performance

The key is that all these COTS or proprietary add-on products are tools. Used with full knowledge of their capabilities and vulnerabilities, these tools can enhance the security of a process, device, or system. Used alone, each provides some benefit, but when skillfully combined with other tools, they create an overall system that provides security greater than the sum of the individual parts. Knowing when and which tools to use to achieve the required benefit without imposing undue restrictions or processes is where the work really begins. In other words, good application or system design begins with the business process requirements, and this is what drives the design. Incorporating security from the beginning is the key. We discuss this further in Chapter 12 , "Define and Design."


Chapter 8. Privacy

Part of the inhumanity of the computer is that, once it is completely programmed and working smoothly, it is completely honest.

—Isaac Asimov

Privacy is a necessary component of any security discussion. Privacy and security must be considered separately, as well as together. Threads of privacy are visible throughout our procedure of building security in to a system or product. The privacy examined in this chapter consists of a group of issues that are inherently privacy and not directly security.

The notion of privacy is protected by governmental policies and laws in certain cases. To be well versed in wireless security, you must have a basic grasp of wireless privacy issues. In this chapter we take a look at issues of online privacy, the differences between online and wireless privacy, current legislation, and the effect of location-based marketing on wireless systems and consumers.


The Online Privacy Debate in the Wired World

To understand the industry and public debates about online privacy, it is essential to understand the opt-in versus opt-out debate. This debate has just a few technical implications at present, but properly understanding privacy from the business perspective is important. Privacy is an essential feature of any product or service—and a core business objective. The burden of proving the active presence of privacy to the consumer is required for a successful product. Understanding the legal issues (at the very least, at a high level) is necessary for ensuring that your product meets federal requirements and does not violate consumer rights. At the heart of the current online privacy debate is the tug-of-war between those in favor of opt-in policies and those in favor of opt-out policies.

Although telecommunications carriers are prohibited from revealing certain information, except to law enforcement authorities upon proper request, they are permitted to sell certain personal information with consumers' consent. The types of information that fall into each category are being hotly debated. These debates will likely continue for the foreseeable future. Just how to obtain consumer consent is the heart of privacy arguments. Should users have to opt out of having their information shared and sold, or should companies require them to opt in?

Opt-out policies are the most prevalent form of privacy policies in most industries today. Numerous studies have shown that opt-out notices fail miserably at the task of protecting consumer privacy. The data in question here is customer proprietary network information (CPNI) or consumer-identifying information. Opt-out notices are typically vague, incoherent, and intentionally hidden in verbose agreements. Under the Gramm-Leach-Bliley Act, we have seen that opt-out schemes do not successfully protect CPNI or consumer-identifying information. If users do not actively opt out, businesses share personal information, including addresses, phone numbers, e-mail addresses, purchasing patterns, and even more confidential information, such as social security numbers. Companies profit from users' failure to read fine-print legalese that comes in an envelope full of junk mail.

The Gramm-Leach-Bliley Act requires certain financial and insurance institutions to send notice of an opportunity to opt out before disclosing personally identifiable information. The law is written so that these institutions compose the notices in a readable manner, yet most consumers would be shocked at the failure rate of this requirement. The opt-out policy suggested in the Gramm-Leach-Bliley Act is so poorly constructed and ineffective that the Federal Trade Commission is investigating the matter in a formal workshop.

The wireless carrier industry does not advocate these opt-out policies. It recognizes the burden placed on consumers by privacy violations and does not want its medium, wireless communication, associated with something so annoying. The wireless industry, in general, supports legislation that provides for opt-in policies that are more protective of consumer privacy.

Opt-in policies are gaining ground in the online arena. These policies are designed to facilitate greater consumer control over personal information. The opt-in policies are much more difficult for companies to abuse than opt-out policies. Effective privacy policies should offer a range of choices. When planned correctly, opt-in policies can be better sources of direct marketing than opt-out policies. The consumers who actively request marketing, for instance, are genuinely interested, and companies can save money by targeting only interested parties with mailings. Congress has mandated that the Federal Communications Commission (FCC) implement procedures that protect consumer privacy when using cellular phones and other wireless devices.

Online privacy discussions cover issues besides opt-in versus opt-out privacy policies. Spam and government or private surveillance also come into play. Unwanted messages, spam, are a pervasive problem in the wired world. Automated technologies send e-mails to hundreds of thousands of unwanted recipients daily. Spam is taxing on servers, annoying to consumers, and an abuse of an intended system. To thwart spam, privacy advocates continually battle with Internet service providers (ISPs), e-mail providers, and Internet application providers, with only moderate success. Spam is a privacy concern in that it is unsolicited. Some e-mail clients, ISPs, or corporate servers prevent spam at various levels, but it is largely unavoidable. Every time an e-mail address is used in registering for a Web site or mailing list or is published anywhere on the Internet, it can be picked up and bombarded with unwanted or offensive e-mails.

Government and private surveillance of users' Web surfing habits is a subject of much debate as well. Consumers should not assume that their Web surfing is private, but few of them know the extent to which this data is warehoused and can be used to learn about them. Direct marketing associations learn a lot about which marketing to push to a user by investigating data about where the user spends his time on the Internet.

In addition to tracking Web surfing habits, ISPs store e-mails in repositories for many reasons. In some cases, the storage is for strictly legitimate purposes. If subpoenaed, ISPs are required to produce e-mails sent to or from a given user. The government allegedly views only the name of the sender and recipient and perhaps the date and time the e-mail was sent but not the internal content in its system, called DCS1000.

Flesh-Eating Mammal Changes Its Ways

DCS1000 was initially an FBI project with the very unfortunate name of Carnivore. FBI spokespeople say that dubbing the system DCS1000 was the result of an upgrade, not an attempt to remove the negative associations that resulted from naming the e-mail tracking system after a flesh-eating mammal.

DCS1000 is an FBI technology that aids in gathering information to solve crimes. It is a packed-based communications interception system. DCS1000 comes under heavy criticism because it is not publicly available and because whether it tracks e-mails only after a warrant has been obtained cannot be proved. Many view this technology as an invasion of user privacy. It is a point of contention among all players in the online world. Several privacy groups have already expressed concern that Carnivore may be used in a pervasive fashion to intercept wireless e-mail. These groups believe that industry companies will not be able to provide the proper privacy safeguards with Carnivore technology in place. The FBI asserts repeatedly that it will not use Carnivore to monitor the content of e-mails.


Privacy in the Wireless World

What is different about privacy in the wireless world? The wireless world, in surfing the Internet or viewing e-mail, has the same privacy concerns as the wired world. Wireless carriers, ISPs, phone manufacturers, and application providers alike have access to personal information about users that they must decide how to manage. The wireless industry has a combination of opt-in and opt-out policies for sharing phone numbers, calling patterns, and so on. The problems in the wireless world are a little different.

At the heart of the privacy debate is this: Who should have more control—the user or the business? If users have too little control, they will be slow to adopt technology because of an inherent distrust of businesses. On the other hand, if users have too much control, business marketing opportunities will be limited, and business will not take interest in wireless technologies. The middle ground we are searching for will bring successful applications and will build trust and contentment in consumers.

Privacy policies are the first and perhaps most obvious issue at the heart of privacy discussions. These verbose, obscure, fine-print legalese statements are difficult to read on paper or on a PC and even more difficult to read on a limited display screen. This point may seem trite, but it bears mentioning. The industry should be very careful not to abuse this situation. The wireless industry tends to be sensitive to issues of connection speed, content-heavy transmissions, and compression of data. In the interest of maintaining a strong and happy customer base, wireless carriers will continue to seek readable, shorter privacy policies so that their consumers can remain informed, in control, and untaxed in time, battery cycles, and billing.

Another difference in wireless privacy is the surveillance issue. Yes, wireless users are concerned about government and private corporation surveillance of their call history, PDA Web surfing activity, or wireless laptop data exchange, but privacy concerns go far beyond this. Wireless devices transmit their locations with a certain degree of precision when powered on. Knowing what someone does is certainly an invasion of privacy but does not provide information as potentially dangerous as knowing where someone is. Knowing your location could place you near the scene of a crime, late for work, speeding on a highway. It could enable you to find a lost Alzheimer's patient, catch a teenager coming home past curfew, or get help when lost in a foreign city. There are pros and cons to being able to pinpoint someone's location simply by her possession of a wireless device.

Because the cons range from being invasive to being dangerous, this privacy issue should be taken very seriously.

California—Ahead of the Privacy Curve

The State of California affords more protection of its constituents' privacy than federal laws and laws in most other states. In 1972, the state constitution was amended to include a California resident's explicit, inalienable right to privacy. This right to privacy is subject to legal interpretation in many areas (including communications) but is a big step ahead of its fellow states in the privacy movement.


The Players

The players in wireless privacy discussions are similar to those we have investigated throughout this text. Each one has a different stake in the privacy game. Wireless carriers want to keep their customers happy and do not care what their users are buying or viewing or to whom they are talking—as long as they are paying for service. Wireless carriers tend to be sensitive to privacy concerns and do not want spam. The wireless industry backs proposed privacy legislation with full force. It wants to be seen as a consumer advocate and is smart in doing so. The wireless industry sees itself as being able to set itself apart from the wired industry by establishing a higher standard of privacy protection for consumers.

Application providers, on the other hand, abuse the system if given the chance. If not explicitly prohibited from using opt-out policies, application providers maximize their marketing possibilities by taking advantage of any personal information they can gather. Application providers and wireless advertising companies such as the Wireless Advertising Association (WAA) are generally opposed to regulations on how to manage consumer-identifying information and want the industry to "regulate itself." We have seen how (un)successful that has proved to be in the wired world. Application providers are not concerned with minimizing or maximizing time billed for connection service. They want to sell more of their applications and services. They are not motivated to protect consumer privacy because they hope to avoid establishing a high standard of privacy.

Privacy advocates tend to be technical experts, consumer advocates, and civil liberties enthusiasts. By keeping Congress, the FTC, and the FCC aware of the dangers of lax privacy regulations, privacy advocates pave the way for safer wireless telecommunications systems.


Related Privacy Legislation and Policy

No privacy discussion is complete without investigating legal policy issues governing the industry. Most privacy discussions hinge on laws and their implications for all parties involved in the wireless circuit. Legislation is continually proposed to Congress on both sides of wireless privacy issues. Some legislation is designed to protect consumer privacy, and some is designed to protect the rights of application providers or advertisers to use and manage personal data as they see fit.

The Communications Assistance for Law Enforcement Act (CALEA)

In 1968, a federal law was instituted to permit law enforcement to conduct wiretaps, pursuant to a court order or other legal authorization, to eavesdrop on an individual's conversations. Because technology has changed since the law's enactment, the law has been amended to attempt to keep pace with technology. Congress attempts to maintain harmony among technological advances, law enforcement agencies, and consumer privacy rights advocates.

The Communications Assistance for Law Enforcement Act (CALEA) was adopted by Congress in 1994. CALEA was not designed to expand wiretapping power and use but to standardize its current implementations. Under CALEA, all telephone companies were required to build in to their systems mechanisms that allow the government to intercept communications with relative ease, if necessary. Also subject to this law are wireless service providers, local exchange providers, resellers, or anyone who offers wireless (or telecom) services for hire to the public.

Some law enforcement agencies have used the law to attempt to broaden their justifiable use of wiretapping, but expansion has been kept to a minimum for the most part. The overreaching purpose of this law was to require new technology to facilitate wiretapping and pen registers when necessary. The burden of keeping law enforcement able to use the technology is placed on the wireless carriers, not on law enforcement itself. If every time communications companies changed their technology, law enforcement had to learn it and make changes, this would be an undue burden in the pursuit of justice. Instead, wireless carriers design facilities in to the technology to aid this effort.

Wireless carriers are largely frustrated with the requirements for implementation dictated by CALEA, even several years after its enactment. They claim that they are caught between sacrificing the privacy rights of their consumers and aiding law enforcement activities. They struggle to find a clearly defined set of boundaries inside which they should operate.

E-911

What role does the FCC play in the privacy debate over issues concerning wireless devices? The FCC recognized that it could use information on the whereabouts of thousands of people to help find them in cases of emergency. This information is very valuable. It would be tough to argue that people would not want this information shared with a fire department when they are caught in a fire. Perhaps the most well-known piece of wireless privacy policy is E-911. E-911 rules require that cellular phone service providers maintain information about users' locations and be able to pinpoint users within a certain range. The availability of this information for use in emergency is a great advantage to anyone with a wireless device. The presence of this information also presents a great risk. What else will service providers do with this information, and what does the FCC have to say about it?

The bill forbids cellular carriers with access to location information from using it without the explicit consent of individual cell phone users. Should the information be available at all times or only in case of emergencies? How is it determined that someone is in an emergency? Can you disable transmitting your location? What is the information used for besides emergency assistance? Although the technology will undoubtedly be put to valuable uses, the idea that large corporations and the government know where you are every time you use a wireless device is daunting. If you are an application developer and have appropriately planned for security, privacy must be considered as well.

E-911 applies to wireless carriers but not specifically to application providers. Wireless industry advocates are lobbying for the same restrictions and limitations to be placed explicitly on application providers and all other parties with access to consumer information in the wireless realm. Most of the E-911 discussion concerns cell phone usage, but there are crossovers into PDAs and Global Positioning System (GPS) arenas as well. Service providers who provide Internet access or other wireless services to PDA users should also be responsible for managing consumer-identifying information. GPS constantly transmits location information about users—another body of information that should be guarded carefully and disseminated only with user consent and justified need for disclosure.

The E-911 rules required that by October 1, 2001, companies had to produce handsets equipped with location-identifying technology or must change their networks to allow for location determination by signal strength. This deadline to complete a portion of the implementation was extended, and requirements and timelines will continue to evolve. The final deadline for compliance still looms ahead, in December 2005. The rules, however, leave it up to providers to figure out how to pay for providing location information to emergency services. (This could encourage providers to sell this information to recoup some of their costs.)

E-911 specifies mandatory conditions for nationwide carriers. Each carrier proposed upgrades that will help it approach compliance with the E-911 requirement that it be able to identify the location of 95 percent of its users. For all carriers, their devices and networks must be capable of identifying a user's location within a certain distance over a certain percentage of time. Some carriers chose to implement device-based solutions, and others chose network-based solutions.

E-911 Location Accuracy Requirements

For device-based solutions:

· 50 meters for 67 percent of the time

· 150 meters for 95 percent of the time

For network-based solutions:

· 100 meters for 67 percent of the time

· 300 meters for 95 percent of the time

The deadline of October 1, 2001, came and went without any carrier meeting the deadline. Extensions have been granted, and eventually this capability will be status quo for all national carriers. With the new capabilities implemented, emergency services will pinpoint a cellular phone or wireless device user from anywhere in the country without the use of a powerful locator tool such as a directional antenna.

E-911 will continue to affect wireless projects and applications and will, it is hoped, provide help in emergency situations without inciting violations of consumer privacy.

The Wireless Communications and Public Safety Act of 1999

The gist of the Wireless Communications and Public Safety Act is twofold. First, it establishes an official framework for guaranteeing universal access to 911 for all Americans with wireless phones. Second, it provides privacy protection in a general sense for an individual's location information. Before this legislation, location information was not included in consumer information protected under any privacy statutes. This legislation marks an important Congressional opinion that wireless privacy is inherently different from other forms of privacy because of the nature and amount of information potentially stored and revealed about users.

The law restricts telecom companies from selling location information about consumers without their consent. It provides privacy protection explicitly for mobile wireless location information. The law is full of holes. Companies are hard-pressed not to test the boundaries of this law. Policing the abuse of location-based technology is difficult. If location information is used as a basis for decision making but is properly hidden as such, it is difficult to detect and prevent. Enforcing this policy is left to astute consumers who recognize the abuse of power that some wireless companies could exert. Companies and the government will press the boundaries of the law. To remain in compliance with the law and future legislation, it is extremely important to consider protecting location information about consumers by offering only opt-in programs for disclosing this information for profit.

The Wireless Communications and Public Safety Act serves as an impetus for expediting the implementation of E-911 regulations nationwide. This causes relief and angst alike. Another piece of legislation that forwards the case for governmental collection of personal communications information is the U.S.A. Patriot Act of 2001.

The U.S.A. Patriot Act of 2001

How does September 11, 2001, affect wireless privacy legislation? There was a marked concern across the nation that our intelligence-gathering and communications-interception capabilities were not up to par. Analysis of data collected from wiretapping (or wireless tapping, as the case may be) is at a premium and comes with a high cost. The desire to compensate for this terrible incident is driving legislation that will facilitate government collection of a wide selection of all forms of communication.

Many privacy advocates are concerned that privacy will take a backseat to patriotism and efforts to stamp out terrorism. The jury is still out. Certainly it is essential to provide law enforcement with the means necessary to track down terrorist activity in any medium, but this must be done within a system of expeditious checks and balances. On October 11, 2001, Congress passed the U.S.A. Patriot Act (Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism) of 2001. The law is termed the Anti-Terrorism Act in some drafts and is referred to by this name when being used familiarly.

The U.S.A. Patriot Act of 2001, enacted in the wake of September 11, assigns new provisions to existing laws and renders moot some points in others. The driving force behind the law is the need to ensure that officials have procedures in place to facilitate the detection, prevention, and eradication of terrorism and that there are no procedures that could slow down progress in this quest.

One feature of the law, which was signed by President George W. Bush, stipulates that law enforcement's use of pen registers and wiretapping devices can include any communications medium, including the Internet, for the purpose of helping detect or combat terrorism. The language of the law is person-specific, rather than device-specific or phone line–specific. All communications of an individual can now be monitored if that person is suspected of illegitimate activities. Although the expansion includes new mediums, it does not provide for the interception of the communication's content (for example, the text of an e-mail, dollar amounts in financial transactions, dialog in a wireless phone conversation). The discoverable information is limited to higher-level information, such as dialing, routing, signaling, and addressing information.

The U.S.A. Patriot Act allows the FBI to use its DCS1000 technology for monitoring e-mail and other communication, to avoid placing undue burden on wireless carriers to implement technical solutions in a costly and rapid manner. This may worry staunch privacy supporters and will have to be monitored closely. If ISPs or independent parties keep tabs on the operations, the DCS1000 system can be used effectively for fighting terrorism but not for invading consumer privacy.

The U.S.A. Patriot Act may have implications for smaller operations than national ISPs, however. Applications that serve any sort of communication or transaction function could be subject to governmental observation. It is important to define clear privacy policies and explicitly detail for customers which information about them is stored and for how long, who has access to it, and under what conditions it is disseminated.

Keeping Up with Wireless Legislation

Information about the most recent legislation relating to wireless technologies is available at http://wireless.fcc.gov. This site typically includes wireless policies whether or not they directly include the FCC.


Location-Based Marketing and Services and GPS

While the issues associated with E-911 are being ironed out, there is another category of location-based information that is less defensible: E-411. Unofficially, E-411 is the use of location information about wireless device users to tailor target marketing. The theory behind location-based marketing is that users can have instant access to information about opportunities around them: movie theaters, stores, and restaurants, to name a few. The marketing in this case might be in the form of a coupon to your favorite coffee bar that appears on your PDA as you drive past a new location or a commercial jingle for a department store that plays on your cell phone when you are in the parking lot outside a mall.

When you are on the wired Internet, you can order products from nearly anywhere at any time of the day or night. Physical stores, however, have hours of operation and specific locations. If you are in an unfamiliar part of town and are getting thirsty, coffee shops want to know. If you are on your way to a relative's house and need to pick up a last-minute gift, stores want to know. In many cases, simply knowing a user's location can enable companies to transmit meaningful information to the user. The concern you need to be aware of if you are developing an application for such a company is that the user should be in control of this information. It should be highly personalized, meaningful, transmitted only upon the user's initial consent, and turned off without hassle.

Wide potential exists with GPS and location-based technologies. GPS is seen in automobiles and sometimes integrated into wireless devices. Its primary function is to locate a user's latitude and longitude to provide maps, directions, or other requested information based on location. A movie theater might give a cell phone company the percentage of ticket sales that come from users who are directed to the theater while in the area. GPS and location-based marketing will be met with high success if they are implemented respectfully.

Push marketing, marketing that is unsolicited and pushed down to a user's wireless device, does not respect a user's privacy and should be used sparingly. Using a cell phone as an example, we note that making a phone call is inherently different from location transmission because the phone call has to be initiated. The user must dial and complete a call actively. Transmitting that user's location, however, is not initiated; it happens automatically any time the phone is on.

This location transmission could be dangerous if it gets into the wrong hands. The fact that you went to a medical clinic yesterday, for instance, should not be offered freely to any interested party. Medical information is typically protected in many instances, and wireless location-based information should not preempt this protection. If health insurance companies knew your history of doctor visits, they could increase your health care premiums. Similarly, if an automobile insurance company knew that you typically travel to a section of town that has a high crime rate, they could increase your insurance premiums.

The Fourth Amendment specifies that an unlawful search occurs when an individual's reasonable expectation of privacy is violated. It specifies that an unlawful seizure occurs when an individual's property is taken with unreasonable interference. In high-tech surveillance, scores of cases have been decided based on search and seizure provisions. The courts have developed a substantial body of decisions on which we base wireless surveillance legality decisions. With respect to GPS, however, courts have yet to make definitive rulings on the constitutionality of law enforcement tracking.

Researchers in the commercial litigation department of Thelen, Reid and Priest, L.L.P., note that the United States Court of Appeals in the ninth circuit addressed the installation of a GPS tracking device underneath a suspect's car without his knowledge. The court held that there was no unconstitutional search on the part of the law officers because the individual should not have a reasonable expectation of privacy. (His expectation of safety, that the device not threaten his life or damage his car, was not violated either. Had it been, this would have been a different case.) Furthermore, the court found that because his car, his property, was not out of his control, it was also not a seizure violation. Cases such as this will continue to unfold as law enforcement experiments with technology and the laws are tested and interpreted.

What is important to understand from a business perspective is that new technologies may be covered under constantly changing bodies of case law and it is essential to stay current with laws related to technologies, services, or products you may be developing. If you create a system that fits in a tight security model and your business practices respect the privacy of your users today, this does not mean that legislation will always protect your practices. GPS in rental cars sometimes broadcast the user's location to the rental agency. The handling of this data is precarious and should be treated with care.

Legislation governing the maintenance and dispersal of location information varies greatly across the globe. In Ireland, for instance, two major wireless carriers maintain what they call customer locator records. These records contain information about where a user is located, with an accuracy of about 10–15 yards. The location information is available during the time the phone is powered on, not just when it is placing, receiving, or in the middle of a call.

These companies believed that they were required by Irish statute to maintain the records and had been storing them for more than six years. The Irish Council for Civil Liberties, shocked when it learned of this storage, investigated the matter. It turns out that holding a locator record for more than a few months is against Irish law and European Union (EU) regulations. The Irish Data Protection Commission is attempting to reconcile privacy and data storage regulations.

The EU has strict data privacy laws, far more stringent than U.S. privacy legislation. Some confusion exists in the EU about which data must be stored and which data must not be stored. This presents a problem for businesses that strive to be in compliance but are at a loss for explicit guidelines under the law. At present, U.S. and British organizations are lobbying the EU to relax its strict data privacy regulations in favor of allowing companies to mine data collected on its wireless users.

Big Brother Catches Speed Demon

A patron rented a car from a rental agency in Connecticut during the summer of 2001. He skimmed the rental legal agreement, signed the form, and departed for Virginia. A few days later he used his ATM card and discovered that the rental car agency had deducted $450 from his account. It turned out that this unlucky patron neglected to read a clause in his contract stating that his vehicle was equipped with a GPS tracking device and that sustaining speeds above 80 miles per hour for more than two minutes would result in a fine. The gentleman was fined for three such incidents. The rental agency maintains that it used this tracking system so that it could track stolen or lost cars, not as a money-making tactic. Is this big brother at work? Are our roads safer for this? Do you read your entire rental car contract? Should you? Should you have to? Apparently, if you don't, it can cost you.


The Middle Ground Answer

The requirements for effective privacy protection are simple and concise. If implemented correctly, a few alterations can produce a mutually beneficial result for consumers and businesses. The Cellular Telecommunications Industry Association (CTIA) set forth guidelines for determining appropriate privacy protection, based on other wired industry privacy standards. The association wants consumers to feel comfortable and safe using wireless technology and believes that the onus for providing comfort and safety falls on all industry players. The CTIA proposed four principles to the FCC and suggested that the standards be used for managing how vendors, manufacturers, service providers, and carriers collect and use location-based and personal information. The principles are as follows:

· Inform all customers about the collection and use of their information.

· Allow a meaningful opportunity for consumers to agree to the collection or use of the information (before using it).

· Protect the security and integrity of any data collected, allow customers access to the data, and give them the opportunity to refute and revise data about themselves.

· Keep privacy rules consistent across platforms, applications, technologies, and use cases so that users do not have undue burden following privacy options.

These principles should be applied to any system being designed. They have high-level and low-level technical implications, coupled with a widespread effect on business. Consumers will demand privacy. Building it in from the start saves time and money and gives your product or system an attractive market differentiator.

We are certainly not advocating against any sort of personalized marketing—we assert only that controlling the delivery and receipt of this information should be left up to each individual. A recipe for success in using your customers' personal information to provide additional recommendations should combine the principles just listed. Personalization, consent, and control are of utmost importance in this day and age. As we mentioned when discussing the need for a comprehensive, provable, and well-tailored security plan, customers will demand it. No longer is there tolerance for security and privacy weaknesses in products or services. Consumers want a guarantee they can trust before handing over their money. Who can blame them? Effective privacy practices and policies enable consumers to maintain the control they need but do not obstruct businesses or marketing effectiveness.


Progress in the Wired World

Although security in the wired world is becoming standardized and advanced, privacy is still a hot topic and up for much consideration and change. The current progress is being made by privacy and technology industry groups alike. Research on privacy tools, Internet filters, privacy requirements, and privacy legislation will be ongoing. Exploitations of consumer information will rear their ugly heads if corporations do not espouse and enforce strict, clear, feasible privacy policies. The wireless world has a chance to jump ahead and learn from the mistakes of its wired counterparts. Privacy should be built in from the start, intertwined with security, and given due attention.


Part IV: I-ADD

Chapter 9. Identify Targets and Roles

Chapter 10. Analyze Attacks and Vulnerabilities

Chapter 11. Analyze Mitigations and Protections

Chapter 12. Define and Design


Chapter 9. Identify Targets and Roles

Chance favors the prepared mind.

—Louis Pasteur

Now we begin to apply our I-ADD security analysis process, described in Chapter 2 , "Security Principles." As you may recall, the I-ADD security analysis process consists of four phases:

· Identify targets and roles.

· Analyze known attacks, vulnerabilities, and theoretical attacks, generating mitigations and protections.

· Define a strategy for security, mindful of security/functionality/management trade-offs.

· Design security in from the start.


Identify Targets

The first step in the process is to identify the system's high-level functional blocks. In Chapter 2 , we identified six high-level functional blocks of a typical wireless system (see Figure 9.1 ). After the blocks are identified, an examination of each is performed to identify the resource or information targets within it that should be protected. After you break down the wireless system to its fundamental components and produce a list of targets, you examine these targets and generate a list of associated roles.

Figure 9.1. A typical high-level wireless system

The Wireless Device

We begin our examination of each of these high-level blocks with the wireless device. At this highest level, the only obvious target is the device itself. A statement of the target at this level is something like the following:

Wireless Device

The wireless device itself

Although this may seem obvious, it is provided here to introduce a methodical and consistent method for identifying targets, or components of a system that need to be protected. This is as far as you can go at this level, so you repeat the process at the next lower functional level (see Figure 9.2 ).

Figure 9.2. A wireless device broken down to the next functional level

There is no right or wrong way to determine how to break the functional blocks down to their next level. Experience and trial and error yield the best breakdown for any given system. A method or approach that works well for one system may not provide adequate results for another. Should you choose an alternative breakdown, such as that shown in Figure 9.3 , you may encounter repeated functional blocks at lower levels. You may have functional blocks with certain branches that can no longer be broken down and other branches that continue for several levels, as shown in Figure 9.4.

Figure 9.3. An alternative breakdown of a multifunction phone

Figure 9.4. A continued breakdown of a multifunction phone

This does not matter, as long as you examine all aspects of the functionality of the system component being analyzed. If our approach is followed, you cannot help but cover all aspects of the system. Figure 9.5 shows a possible breakdown of the multifunction phone depicted in Figure 9.4, but following the delineation started in Figure 9.2.

Figure 9.5. An alternative breakdown of a multifunction phone

We could debate whether auto dial is an offline or online function (it is assumed to be an online function for this example). The intent is not to break down an actual cell phone completely but to demonstrate that the same result can be reached with differing approaches. An actual cell phone can have many additional features and administrative functions, and the transceiver could be broken down to transmitter and receiver or to administrative/overhead transmissions and payload transmissions, and so on. The important thing to notice is that the same 10 branches of the breakdown tree are present in both Figure 9.4 and Figure 9.5. The ends of these branches are microphone/speaker, keypad/display, usage monitor, settings, contacts, e-mail read, e-mail compose, auto dial, speech, and transceiver. The choice of functional breakdown is left to your preference and the type of application or device being analyzed.

Now that we have shown a breakdown for a typical multifunction cell phone, let's assume that the wireless device is a typical wireless PDA. This serves two purposes. First, you do not have to consider voice communications. Second, you will not jump ahead because you already know how the next level will be broken out. Figure 9.6 shows the wireless PDA broken down to the second functional level. Examining each functional block, you repeat the earlier process of identifying targets or components to protect.

Figure 9.6. A wireless PDA showing the second functional level

The User Interface

Examining the user interface at this level, you consider the need to protect the display and keys from damage or inadvertent input while the device is being transported (after all, the whole point of wireless is to enable mobility). Now, you may be wondering, why are we concerned about damage to the display in a security book? Recall that one of the security principles discussed in Chapter 2 is Integrity. We assert that integrity applies not only to data but also to the system. Under this premise, the ability to access data on demand is a security concern. Furthermore, if the screen becomes damaged, can you guarantee that the information you receive is accurate? It is not outside the realm of possibility for a user to misinterpret a letter because the confirmation code received contains an O instead of a U and the display is damaged where those pixels should be. Arguably, this would fall under the Development and Operational principle of Functionality or Utility. This is certainly true, but also recall that these principles are often related and interdependent. Your list now looks like this:

Wireless Device

The wireless device itself

User Interface

The physical interface

Access to the user interface

Offline Functions

In examining offline functions, several potential targets come to mind. Personal data— such as information in an address book or calendar files (names, addresses, phone numbers, or public and private keys)—stored on the PDA should be protected from unauthorized access. As m-commerce becomes more prevalent, PDAs will store bank account, brokerage, and credit card information that must be protected. Corporate or other nonpersonal information housed on the PDA should be protected. The list of data potentially stored on a PDA extends as far as the imagination (and device engineers) will allow. The point is that no one other than those who are authorized should have access to information stored on the PDA.

Online Functions

In examining online functions, the same offline concerns apply. The difference is that unauthorized access is obtained as the information transits the air or the wired network. In addition to data, the user's activity and usage patterns should not be available to unauthorized parties. This introduction of additional data to protect is not the whole picture, though. The user's location and movements are also in need of protection, with the incorporation of GPS technology into wireless devices. Finally, spoofing the user (the use of the device or a similar device by an unauthorized user pretending to be an authorized user) to obtain service or data should be disallowed.

The Transceiver

The transceiver should be protected from tampering by someone who has gained unauthorized access to the device. By way of example, the transceiver could be changed in such a way that it always accesses a different service provider's transceiver or an attacker's transceiver. (Spoofing the device's service provider, vulnerabilities, and attacks are discussed in greater detail in Chapter 10, "Analyze Attacks and Vulnerabilities.") The attacker then communicates with the service provider, on the user's behalf, thereby giving the attacker the ability to monitor and control the user's activities.

Now, if you are imagining the intricacies that must fall into place for this to occur, you may immediately think that this is an awfully elaborate man-in-the-middle attack and not very likely to occur against the average wireless user. Although we concur, keep in mind that the goal of this phase is to identify targets for completeness, separate from any assessment of vulnerability or likelihood of realization. The task of prioritizing and making those kinds of trade-offs occurs during the I-ADD define phase. To be aware of the full set of risks associated with a given system, all possible attacks must be examined. Ruling out the least feasible ones is the secondary and simpler part.

Each functional block at this level is then broken down to the next functional level. We will not do so here because the discussion would become too dependent on the specifics of the PDA or application being used. Further, many of the preceding issues would simply be repeated for each of the lower-level blocks, particularly under the two Functions boxes. However, in analyzing a specific PDA or application for wireless use, this process should continue to the same depth as the functional design process to ensure that security issues are considered for these lower-level functional blocks as well.

Examining the targets list at this point yields the following:

Wireless Device

The wireless device itself

User Interface

The physical interface

Access to the user interface

Offline Functions

Personal data on the PDA

Corporate or third-party information

Online Functions

Personal data being sent

Corporate or third-party information being sent

User online activities, usage patterns

Location and movement

Access to network and online services

Transceiver

The transceiver itself

The Service Provider

The next functional block to examine is the transceiver of the service provider (refer to Figure 9.1). For the sake of brevity, we use the term transceiver here, although the component we are referring to is the service provider infrastructure, which provides wireless connectivity between the wireless device and the rest of the wired world. At this level, the transceiver needs to be physically protected. Logically, it needs to protect its services from unauthorized use. From the wireless side, the transceiver needs to ensure that users are authorized to use its services. From the wired side, the transceiver—or more appropriately, the service provider—needs to ensure that its services are accessed only by authorized entities and thereby obtains access to the wireless users.

As with the wireless device, when this level is complete, you break it down to the next functional level (see Figure 9.7).

Figure 9.7. A second-level breakdown of the transceiver

The Transceiver

For our purposes, we do not need to drill further beyond the higher-level targets. If a functional block is identified, it should be listed and retained so that there will be no confusion about whether it was considered by others or during a review at some point in the future.

This is an appropriate time to state something that may or may not be obvious. A common target across all functional elements is physical protection. Having physical access to a device or resource makes an attacker's job much easier. Hence, perimeter security fencing, the presence of armed guards, as well as locks and alarms on buildings contribute greatly to overall security in wired systems. With wireless systems, this fundamental aspect of security goes right out the window. Wireless systems eliminate the need for legitimate and illegitimate users to have physical access to the network. Put another way, unless you encase the wireless system in an RF shielded enclosure, an attacker is going to be able to identify the network, and no number of armed guards around the tower is going to prevent her from attempting to access the system if that is her intent. This doesn't mean that you should just pack up your bags and head home. Quite the contrary, you need to acknowledge this fact and design systems that are secure in spite of this big plus in the attacker's column.

The Administrative Server

Two additional targets become apparent when examining this functional block. First is user-specific data, which must be protected from unauthorized disclosure. Second is corporate proprietary data or resources, which must be protected from unauthorized disclosure. We will not break the service provider down to additional functional levels. For our purposes, this is sufficient. However, we do want to point out that the administrative server can be broken down to several additional levels, depending on the service provider architecture. Potential lower-level functional blocks would be authentication functions, billing functions, fraud detection functions, and performance monitoring functions.

The Network Server

This functional block is likely to have corporate proprietary data or resources that must be protected from unauthorized disclosure. As with the administrative server functional block, we will not break this functional block down any further because it quickly becomes provider-specific.

This completes the service provider functional block, and the targets list now looks like this:

Wireless Device

The wireless device itself

User Interface

The physical interface

Access to the user interface

Offline Functions

Personal data on the PDA

Corporate or third-party information

Online Functions

Personal data being sent

Corporate or third-party information being sent

User online activities, usage patterns, location and movement

Access to network and online services

Transceiver

The transceiver itself

Transceiver (Service Provider)

The transceiver itself

The transceiver services

Access to its subscribers

Transceiver

Administrative Server

User-specific data

Corporate proprietary data and resources

Network Server

Corporate proprietary data and resources

The identify phase is then continued to the next functional block of Figure 9.1, the gateway. The gateway's role is discussed in Chapter 1, "Wireless Technologies." Although the term gateway is most associated with cellular phones, its function of converting standard Web pages to the format used by wireless devices is common. These gateways can be co-located with the Web servers or with the wireless service providers.

The Gateway

Examining the high-level functional block, you can readily identify several targets. The gateway must be physically protected from loss or theft. User-specific data must be protected from unauthorized disclosure. The user's data must be protected from unauthorized disclosure. Corporate proprietary data and resources must be protected from unauthorized disclosure. Third-party data must be protected from unauthorized disclosure as it transits the gateway. The integrity of the data processed by the gateway must be maintained.

The gateway can be broken down to additional functional levels, but we will not do so here. By now, the process should be clear, so we do not want to belabor the point. Likewise, we will not break down the remaining high-level functional blocks listed in Figure 9.1. The following is the complete target list:

Wireless Device

The wireless device itself

User Interface

The physical interface

Access to the user interface

Offline Functions

Personal data on the PDA

Corporate or third-party information

Online Functions

Personal data being sent

Corporate or third-party information being sent

User online activities, usage patterns, location and movement

Access to network and online services

Transceiver

The transceiver itself

Service Provider

The transceiver itself

The transceiver services

Access to its subscribers

Transceiver

Administrative Server

User-specific data

Corporate proprietary data and resources

Network Server

User data

Corporate proprietary data and resources

Gateway

The physical gateway

User-specific data

User data

Corporate proprietary data and resources

Third-party data transiting the gateway

Web Server

The physical Web server

User-specific data

User data on the Web server

Corporate proprietary data and resources on the Web server

Aggregate commercial data stored on the Web server

User or corporate data in transit

Backend System

The physical backend system

User-specific data on the backend system

User data on the backend system

Corporate proprietary data and resources on the backend system

Aggregate commercial data stored on the backend system


Identify Roles

The second step in the I-ADD process is to identify the roles associated with the system. Let's review what we mean by roles. A role is simply an individual or group of individuals who plays a role in either protecting or exploiting a target. As we proceed through the process of identifying roles, this should become clear. At this point, the easiest way to proceed is to go through the targets list and identify the roles associated with each target. We will not explain these roles in detail here. As you read through the list, try to identify why each role is listed where it is. We discuss the roles in more detail in the section " Vulnerabilities and Theoretical Attacks " in Chapter 10 .

Malicious Users

You will soon notice the ever-present malicious user. The term malicious is used liberally. What we are referring to is an individual or group who has the knowledge, skills, or access to compromise a system's security. Malicious user is a generic category encompassing a variety of roles that deserve additional discussion. A malicious user can be any of the following.

Organized Crime (Financial Motivation)

These malicious users are capable, motivated, well organized, and well funded. They are intent on operations such as cloning cell phones or other wireless devices and stealing money, goods, and services. Organized crime is the most capable category of attackers. Their ability stems from having the resources available to obtain the necessary hardware, software, and knowledge to mount sophisticated attacks quickly if the potential financial benefits justify the effort.

Hackers (Nonfinancial Motivation)

These malicious users are also capable, motivated, and well organized and may be well funded. Although hacker interest in wireless systems may initially be sparked by the financial or proprietary information the system protects, their attacks are generally focused on achieving notoriety. Attacks that can be expected of hackers include small-scale and wide-scale disruption of operations and the collection and release of sensitive information.

Malicious Programmers (Financial or Brand Damage)

These malicious users vary in their technical ability and are usually highly motivated by personal greed, grievance, or grudge. They are usually not well organized but may possess significant knowledge of the wireless system and access to internal processes. Malicious programmers can originate from various sources: a disgruntled employee at a wireless manufacturer; an application programming contractor; operations and support personnel; a knowledgeable programmer who feels wronged by someone associated with the manufacture, distribution, or management of a wireless system or device; a programmer who feels wronged by an individual or a company using wireless systems or devices.

Also in this group we consider attackers with nonmalicious intent whose actions can incur security issues, either inadvertently or because of an interest in improving the system's security. The information and vulnerabilities generated by nonmalicious attackers are capitalized on by malicious attackers if not immediately addressed by the affected wireless component or system.

Academics and Security Researchers

These attackers are capable, motivated, well organized, and often well funded. Academics and security researchers can analyze the security of a wireless component or system from an intellectual standpoint to determine how the system is designed or whether and how potential vulnerabilities have been addressed. They look at both the theoretical and practical implementation of the system, focusing primarily on issues in their area of expertise for the purposes of advancing the field, or their standing in the field. Although this group does not have malicious intent, malicious attackers can use their findings before mitigation or corrections are in place. This group is more likely to inform the vendor when a vulnerability is detected, before publishing their results, although this is not guaranteed.

Inexperienced Programmers and Designers

Although they do not fit most standard definitions of a malicious user, inexperienced programmers and designers can inadvertently create security issues and are considered malicious for this analysis. These inexperienced personnel are motivated to perform a specific task to support a wireless system, but they do not possess the skill or experience necessary to execute the task properly. The mistakes and oversights made by these personnel affect the operation of wireless components and can adversely affect the security of the wireless system. Other attackers exploit the vulnerabilities generated by inexperienced personnel.

Mapping Roles to Targets

Wireless Device

The wireless device itself

Device manufacturer

User

Malicious user

User Interface

The physical interface

Device manufacturer

User

Environment

Access to the user interface

Device manufacturer

Application (app) developer

User

Environment

Offline Functions

Personal data on the PDA

Device manufacturer

Device support personnel

App developer

App support personnel

User

Malicious device support personnel

Malicious app developer

Malicious app support personnel

Malicious user

Corporate or third-party information

Device manufacturer

Device support personnel

App developer

App support personnel

User

Malicious device support personnel

Malicious app developer

Malicious app support personnel

Malicious user

Online Functions

Personal data being sent

Device manufacturer

Wireless service provider (WSP)

WSP operations, maintenance, and support personnel (OMS personnel)

App developer

App support personnel

User

Malicious WSP

Malicious device support personnel

Malicious WSP OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

Corporate or third-party information being sent

Device manufacturer

WSP

WSP OMS personnel

App developer

App support personnel

User

Malicious WSP

Malicious device support personnel

Malicious WSP OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

User online activities, usage patterns, location and movement

Device manufacturer

WSP

WSP OMS personnel

App developer

App support personnel

User

Malicious WSP

Malicious device support personnel

Malicious WSP OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

Access to network and online services

Device manufacturer

WSP

WSP OMS personnel

App developer

User

Malicious device support personnel

Malicious WSP OMS personnel

Malicious app developer

Malicious user

Transceiver

The transceiver itself

Device manufacturer

Device OMS personnel

User

Malicious device OMS personnel

Malicious user

Service Provider

The transceiver itself

WSP

WSP OMS personnel

Malicious OMS personnel

Malicious user

The transceiver services

WSP

WSP OMS personnel

Malicious OMS personnel

Malicious user

Access to its subscribers

WSP

WSP OMS personnel

Corporate/private servers

Corporate/private server OMS personnel

Content providers

App developer

App support personnel

User

Malicious WSP OMS personnel

Malicious corporate/private servers

Malicious corporate/private server OMS personnel

Malicious content providers

Malicious app developer

Malicious app support personnel

Malicious user

Transceiver

Administrative Server

User-specific data

WSP

WSP OMS personnel

App developer

App support personnel

Malicious WSP OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

Corporate proprietary data and resources

WSP

WSP OMS personnel

App developer

App support personnel

Malicious WSP OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

Network Server

User data

WSP

WSP OMS personnel

App developer

App support personnel

Malicious WSP OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

Corporate proprietary data and resources

WSP

WSP OMS personnel

App developer

App support personnel

Malicious WSP OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

Gateway

The physical gateway

Gateway manufacturer

OMS personnel

App developer

App support personnel

Malicious OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

User-specific data

Gateway manufacturer

OMS personnel

App developer

App support personnel

Malicious OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

User data

Gateway manufacturer

OMS personnel

App developer

App support personnel

Malicious OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

Corporate proprietary data and resources

Gateway manufacturer

OMS personnel

App developer

App support personnel

Malicious OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

Third-party data transiting the gateway

Gateway manufacturer

OMS personnel

App developer

App support personnel

Malicious OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

Web Server

The physical Web server

Web server manufacturer

Web server OMS personnel

Content providers

App developer

App support personnel

Malicious Web server OMS personnel

Malicious content providers

Malicious app developer

Malicious app support personnel

Malicious user

User-specific data

Web server manufacturer

Web server OMS personnel

Content providers

App developer

App support personnel

Malicious Web server OMS personnel

Malicious content providers

Malicious app developer

Malicious app support personnel

Malicious user

User data on the Web server

Web server manufacturer

Web server OMS personnel

Content providers

App developer

App support personnel

Malicious Web server OMS personnel

Malicious content providers

Malicious app developer

Malicious app support personnel

Malicious user

Corporate proprietary data and resources on the Web server

Web server manufacturer

Web server OMS personnel

Content providers

App developer

App support personnel

Malicious Web server OMS personnel

Malicious content providers

Malicious app developer

Malicious app support personnel

Malicious user

Aggregate commercial data stored on the Web server

Web server manufacturer

Web server OMS personnel

Content providers

App developer

App support personnel

Malicious Web server OMS personnel

Malicious content providers

Malicious app developer

Malicious app support personnel

Malicious user

User or corporate data in transit

Web server manufacturer

Web server OMS personnel

Content providers

App developer

App support personnel

User

Malicious Web server OMS personnel

Malicious content providers

Malicious app developer

Malicious app support personnel

Malicious user

Backend System

The physical backend system

Backend system manufacturer

Backend system OMS personnel

App developer

App support personnel

Malicious backend system OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

User-specific data on the backend system

Backend system manufacturer

Backend system OMS personnel

App developer

App support personnel

Malicious backend system OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

User data on the backend system

Backend system manufacturer

Backend system OMS personnel

App developer

App support personnel

Malicious backend system OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

Corporate proprietary data and resources on the backend system

Backend system manufacturer

Backend system OMS personnel

App developer

App support personnel

Malicious backend system OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

Aggregate commercial data stored on the backend system

Backend system manufacturer

Backend system OMS personnel

App developer

App support personnel

Malicious backend system OMS personnel

Malicious app developer

Malicious app support personnel

Malicious user

As you can see, this can quickly become a long list. Now that we have concluded the identification of the roles, it is worth discussing two observations that will assist you in performing future role identification. First, in general, whenever people are involved in protecting a target, they almost always are also listed in the malicious section against that target. We are not saying that the same people will be involved, but that the category of people or that group's level of access can be used maliciously.

This concludes the I-ADD identify phase. You break down the system into functional blocks and then examine each block to determine which resources or data (targets) require protection at that level. The blocks are then examined to see whether they should be further broken down to lower-level functional blocks, where the process is repeated until you reach the lowest-level functional blocks practical for the type of analysis or design you are conducting. After identifying the targets, you determine the roles that affect the targets. With the roles and targets identified, you are ready to move to the I-ADD analyze phase.


Chapter 10. Analyze Attacks and Vulnerabilities

. . . man will occasionally stumble over the truth, but usually manages to pick himself up, walk over or around it, and carry on.

—Winston S. Churchill

The second phase of the I-ADD security process is the analyze phase. During this phase you examine known attacks, vulnerabilities, and theoretical attacks in order to generate protections and mitigations. These protections and mitigations are methods or procedures used to inhibit an attacker's ability to exploit a vulnerability or perform an attack. The protections and mitigations should be identified without consideration for other factors, such as cost, limits to functionality, or time to implement. Trade-offs are evaluated and decisions are made during the next I-ADD phase, the define phase.


Known Attacks

Identifying known attacks requires research of security-related Web sites, papers, and trade journals. Although currently known attacks are few in number, relative to wired systems, they are likely to grow as wireless systems become more prevalent and provide a richer target for the attacker community. The known attacks we cover here are specific to the wireless portions of the system. The Web servers, backend servers, and gateways are all subject to known attacks specific to their hardware platform, operating systems, and ancillary applications. The importance of specifically examining known attacks separate from theoretical attacks is that known attacks are likely to be attempted by an attacker when targeting a wireless system. Therefore, known attacks deserve a higher priority when making trade-offs during the next I-ADD phase.

Device Theft

Device theft is just as it sounds, the physical theft of the device by an attacker. Fortunately, this is not a concept new or unique to wireless devices or systems, so the need for protection of wireless devices and systems against physical theft is intuitive to device and system manufacturers. Unfortunately, devising devices or systems resistant to theft is very difficult.

Several mitigations can be employed to minimize the threat. We will not spend much time stating the obvious, such as locking and alarming rooms that house equipment.

The Man in the Middle

The attacker, by interjecting herself between the user and the server, accomplishes the well-known man-in-the-middle network attack. This interjection is done by gaining physical access to the logical or physical path between the user and the server, such as sitting at the user or server's access point to the network. Alternatively, this can be used to spoof the user to the server and the server to the user. In both scenarios, the attacker has complete access to the communications between the user and the server.

War Driving

In the 1980s, malicious types began war dialing, calling phone numbers at random in an attempt to locate unprotected modems and gain access to networks. The early 2000s version of war dialing is war driving, roaming around with a laptop, wireless NIC, and an antenna and attempting to gain access to wireless networks. As we have discussed, the vast majority of wireless networks deployed do not use WEP or use WEP without implementing RSA's Fast Packet Keying solution to (more or less) security. With a $100–150 wireless NIC set in promiscuous mode and a cheap parabolic grid antenna from Radio Shack, hackers have gained access to thousands of wireless networks across the United States. In populated areas, war drivers have used simple GPS applications in combination with the wireless NIC and antennae and have successfully mapped the location of thousands of wireless networks to which they can gain access. No esoteric software or hardware is required. A software application called AirSnort has the ability to analyze the intercepted WEP traffic and, after collecting enough data, even determine the root password for the wireless system.

Denial of Service

Denial of service is a class of attacks that take many forms, from subtle to obvious. An obvious denial of service attack against a wireless system would be to sever the coax cable on the tower between the transceiver and the antenna. This definitely would deny service to anyone wanting to use that particular tower. A more subtle attack would be to tie up the system with service requests or to spread a bogus e-mail such as "New and Destructive Virus," explaining that you should e-mail everyone you know so that they can protect themselves. The desired result is that the system becomes so bogged down with these e-mails that legitimate traffic cannot be accommodated.

Another popular denial of service attack is the "Please help, my child is dying." An e-mail is sent saying that someone, usually a hapless child, is suffering from a terrible affliction. The e-mail goes on to say that a corporation has agreed to provide X amount for every e-mail it receives regarding this child, so please forward this e-mail to everyone you know so that this child can be saved. The desired result is to overwhelm the corporation's servers and cause them to crash.

The DoCoMo E-Mail Virus

As of the writing of this chapter, there have been two similar virus attacks against Japan's DoCoMo cellular system. These attacks are viruses that can be downloaded into multifunction cellular phones. The viruses cause the user's phone to automatically dial a number, such as 911, tying up both the cellular and 911 systems. With little imagination, you can see how this type of activity can have far-reaching and dire consequences.


Vulnerabilities and Theoretical Attacks

Identifying vulnerabilities is a difficult process because you are looking for what might occur and trying to anticipate how an attacker could attempt to exploit the system. The process is a dual-mode analysis in which you are examining potentially vulnerable areas while anticipating theoretical attacks. Based on the success or failure of these theoretical attacks, the particular component or resource is identified as vulnerable. Recall that you are not making any determination at this point about the practicality of an attack or the development trade-offs necessary to protect or mitigate the vulnerability.

To begin the examination of vulnerabilities, you begin at the top of the targets list and place yourself in the malicious roles identified earlier. You then create theoretical attacks to which these targets would be vulnerable. Experience and knowledge of the system's inner workings are crucial if you are to have any expectation of identifying all its potential vulnerabilities. If you are examining an existing system, this requirement may lead you to utilize the developers to conduct the vulnerability analysis. This is acceptable as long as the team is evenly weighted with those who were not involved with the development. The reason is, developers know what they were trying to accomplish, and they may make assumptions about how the system functions or responds under certain circumstances. Further, developers know how the system was intended to function, but most attacks attempt to cause the system to function in a manner in which it was not intended.

Vulnerabilities of the Wireless Device

Similar to identifying targets, you begin at the highest levels and work your way down to the lower functional levels of the system. In general, the lower functional levels require more detailed knowledge, for you to analyze and for an attacker to exploit. However, with any generality, there are always exceptions, particularly with exploits. Once identified by someone with knowledge, even the lower-level functional levels can be successfully exploited by others with less technical expertise. We discuss this in greater detail throughout the remainder of the chapter, looking at specific examples. Suffice it to say that for this analysis, you must try to be as thorough as possible to ensure that the system is fully protected. You begin by looking at the targets identified.

The Wireless Device Itself

The vulnerability, loss, or theft of this particular target is not new to wireless. Loss or theft of personal items has been a concern since our ancient ancestors first grasped the concept of personal property as they huddled around fires in caves. The vulnerability of wireless devices is that they can be misplaced by users or taken by malicious users.

User Interface

The user interface should be examined in its two parts: the physical interface and access to the user interface. These two have different issues that should be acknowledged for completeness of your risk assessment.

The Physical Interface

The physical interface is vulnerable to environmental factors such as water, shock, and abrasion—for example, dropping the device in a puddle or spilling coffee on the device, dropping it off a table, having it slip out of the user's hands, having the device slide across a rough surface, and having someone sit on or drive over the device.

Access to the User Interface

The user interface is vulnerable to environmental factors that cause inadvertent input—for example, a cellular phone in someone's purse being bumped and activated when an object inside the purse depresses the Send key.

Offline Functions
Personal Data on the PDA

Here is where things become more interesting. You examine each of the malicious roles separately to ensure that you cover all the possible vulnerabilities. Again, this is not guaranteed. To ensure a system's security, you must review the vulnerabilities in light of new known attacks, updated information on the system, or new theoretical attacks.

Malicious Device Support Personnel

Personal data stored on the device is vulnerable to malicious device support personnel when the device is taken in for upgrades, maintenance, or repair. These support personnel may have access to manufacturer bypass and diagnostic codes, equipment, or utilities that give them access to personal data stored on the device.

Poor or inexperienced device support personnel may inadvertently leave the device in a security bypass or diagnostic mode that leaves personal data vulnerable.

Malicious App Developer

Malicious application developers can create a virus or Trojan Horse (a program that, in addition to providing an overt useful function, performs a covert activity, usually malicious) utilities or programs that allow access to personal data on the PDA.

Poor or inexperienced application developers may not take appropriate security measures regarding their particular application, such as not clearing buffers and overwriting data elements, leaving personal data vulnerable during transit.

Malicious App Support Personnel

Malicious application support personnel may dupe the user via social engineering to provide access, or information necessary for access, to personal data under the auspices of assisting with an application issue. Alternatively, malicious app support personnel may enable debug or other diagnostic switches within the software, disabling security mechanisms present in the device or software.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled following a support activity, rendering the personal data vulnerable.

Malicious User

Personal data is vulnerable to a malicious user who has gained access to the device. Recall that malicious user is a catchall term encompassing a variety of activities. Although this simple statement is adequate for describing the vulnerability, the complexity of the role becomes important and should not be forgotten when generating mitigations and protections or performing the security-functionality trade-offs. For example, a malicious user may pose as a member of one of the legitimate functional roles and become the functional equivalent of one of the malicious roles just discussed.

Corporate or Third-Party Information

From a vulnerability perspective, no distinction exists between corporate and third-party information and personal data. There may be some distinction when it comes to the security-functionality trade-offs. For example, a device manufacturer may be willing to limit some functionality to ensure the protection of the user's personal data but may decide that the same trade-off for corporate data is unnecessary because its obli-gation ends with the user.

Online Functions
Personal Data Being Sent

This target is personal data as it is in transit. You will notice that all the previous roles are present, with the addition of a few others because of the data's increased exposure during transport.

Malicious Wireless Service Provider (WSP)

Your first thought may be, "How could a WSP be malicious?" In general, WSPs are not. They are in the business of providing wireless services, so performing any untoward activity would be counterproductive. However, consider the following example, based on the office complex scenario introduced in Chapter 1, "Wireless Technologies."

Suppose that AdEx Inc., as a courtesy to its clients, offers wireless access through its network. NitroSoft is visiting AdEx for a presentation of a proposed new marketing campaign. During breaks in the presentation, the NitroSoft representative sends and receives e-mail via his wireless PDA. This information is related to the campaign, including price limits and current bids from other representatives attending similar presentations around the country. The connectivity is much appreciated by the NitroSoft representative because he can discreetly communicate the current status to his NitroSoft co-workers to ensure that NitroSoft receives the best marketing campaign for the money.

What the NitroSoft representative doesn't know is that someone from the AdEx IT staff is monitoring the NitroSoft representative's communications and relaying any pertinent information to AdEx's marketing staff so that they will be well informed of her feelings about the presentation, any misgivings she may have, what NitroSoft's bottom line will be, and possibly what the bids are from other marketing firms.

In this example, is AdEx just doing smart business? After all, AdEx owns the wireless connectivity hardware, and by extension, everything it transports. Or is AdEx a malicious WSP? Unless AdEx had the NitroSoft representative sign an agreement to access its wireless network and this agreement contained a waiver granting AdEx access to anything transmitted over the network, we would vote for the latter. Therefore, personal data transmitted by the device may be vulnerable to a malicious WSP.

Malicious Device Support Personnel

Personal data transmitted by the device can be made vulnerable by malicious device support personnel when the device is taken in for upgrades, maintenance, or repair. These support personnel may have access to manufacturer bypass and diagnostic codes, equipment, or utilities that allow them to bypass security features, leaving personal data transmitted by the device vulnerable.

Poor or inexperienced device support personnel may inadvertently leave the device in a security bypass or diagnostic mode that renders personal data vulnerable during transit.

Malicious WSP OMS Personnel

Personal data transmitted by the device is vulnerable to malicious WSP OMS personnel who have access to the WSP transceiver and wireless network equipment.

Malicious App Developer

Malicious application developers may create a virus or Trojan Horse utilities or programs that cause the transmitted data to be vulnerable. An example would be an encryption utility containing nonunique or known keys. To the user, the data appears encrypted, but it is readily accessible to unauthorized individuals who know the key. Alternatively, an e-mail utility may send a blind copy of every message sent or received by the device to a predefined address.

Poor or inexperienced application developers may not take appropriate security measures regarding their particular application, rendering personal data vulnerable during transit.

Malicious App Support Personnel

Malicious application support personnel may coerce the user via social engineering to provide access, or information necessary for access, to personal data under the auspices of assisting with an application issue. Alternatively, malicious app support personnel may enable debug or other diagnostic switches within the software, disabling security mechanisms present in the device or software.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, rendering the personal data vulnerable during transit.

Malicious User

Personal data is vulnerable to a malicious user who has access to, or has built a receiver that can monitor, the transmission of the PDA and can reconstruct the data transmitted and received. Again, a malicious user can assume any of the preceding malicious roles to gain access necessary to exploit a vulnerability.

Corporate or Third-Party Information Being Sent

As with offline functions, from a vulnerability perspective there is no distinction between corporate or third-party information and personal data in transit.

User Online Activities, Usage Patterns, Location and Movement

This category can be considered a subset or equivalent to user personal data as far as vulnerabilities are concerned. The difference lies in how this type of information can be protected, which we discuss in Chapter 12, "Define and Design."

Access to Network and Online Services

As used here, access to network and online services means the use of the device or information on the device to gain access to network and online services. This distinction separates it from similar activities occurring against the service provider, which we will discuss shortly.

Malicious Device Support Personnel

User network and online services access credentials are vulnerable to device support personnel who have access to the device for upgrade, maintenance, or repair purposes. Device support personnel may have access to manufacturer bypass and diagnostic codes, equipment, or utilities that give them access to network and online services access credentials on the device.

Malicious WSP OMS Personnel

User network and online services access credentials are vulnerable to WSP OMS personnel when this information is received and processed by the WSP equipment. The user may also be coerced into providing network or online access credentials to WSP OMS personnel.

Malicious App Developer

User network and online services access credentials are vulnerable to applications that can copy and store, or forward, these credentials to the developer.

Malicious User

Access to network and online services are vulnerable to a malicious user. A malicious user may gain access to the device and retrieve network and online services credentials, to be used on another device or at a later time. A malicious user may monitor transmissions, discussed under "Malicious User" for personal data being sent to obtain network and online services credentials. Again, a malicious user can assume any of the preceding malicious roles to gain access necessary to exploit a vulnerability.

Transceiver
The Transceiver Itself
Malicious Device OMS Personnel

The transceiver is vulnerable to manipulation or modification by malicious device OMS personnel.

Malicious User

The transceiver is vulnerable to manipulation or modification by a malicious user. For example, this may be done to assist a man-in-the-middle attack.

Vulnerabilities of the Service Provider

The Transceiver Itself

When we use the term transceiver in regard to the service provider, we are considering a transceiver system consisting of the antenna array, tower, coax, transceiver, and switching equipment.

Malicious Device OMS Personnel

The transceiver is vulnerable to manipulation or modification by malicious device OMS personnel.

Malicious User

The transceiver is vulnerable to manipulation or modification by a malicious user. For example, this may be done to deny service to areas or individuals at crucial times.

The Transceiver Services
Malicious Device OMS Personnel

The transceiver services are vulnerable to manipulation or modification by malicious device OMS personnel—for example, granting network access to unauthorized users by providing maintenance or diagnostic access credentials to these unauthorized users.

Malicious User

The transceiver is vulnerable to manipulation or modification by a malicious user. For example, a malicious user may obtain access credentials to utilize the service without paying for the privilege.

Access to Its Subscribers
Malicious WSP OMS Personnel

The service provider is vulnerable to WSP OMS personnel who can grant access to the network, and thereby its subscribers, for spam or other unsolicited purposes.

Malicious Corporate/Private Servers

The service provider is vulnerable to malicious corporate or private servers that access the service provider to deliver advertising, marketing, or other spam to the service provider's subscribers.

Malicious Corporate/Private Server OMS Personnel

The service provider is vulnerable to malicious corporate or private server OMS personnel who utilize authorized servers to perform unauthorized access to subscribers. For example, service provider subscribers receive stock quotes as part of their service plan. OMS personnel with access to the quote server that provides this service could alter the server to deliver anything in addition to, or in place of, the stock quotes.

Malicious Content Providers

The service provider is vulnerable to malicious content providers who use the service provider resources to spam or otherwise deliver their payload to the subscribers.

Malicious App Developer

The service provider is vulnerable to malicious app developers who include back doors or Trojan Horse utilities or programs that the service provider uses. These app developers can then use the privileged access available to their legitimate applications to obtain illegitimate access to the subscribers.

Malicious App Support Personnel

Service provider subscribers are vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the software, disabling security mechanisms that protect access to the subscribers.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, rendering corporate proprietary data and resources vulnerable on the network server.

Malicious User

The service provider is vulnerable to malicious users gaining network access to allow them access to the service provider's subscribers, either by these malicious users' acting in one of the preceding roles or by exploiting a vulnerability in the overall service provider's system.

Transceiver

Recall that there were no targets for the transceiver beyond those identified for the higher-level functional block.

Administrative Server

By administrative server, we are referring to the billing, maintenance, and support systems associated with keeping the wireless infrastructure functional.

User-Specific Data

User-specific data is information such as credit card numbers, address, finances, call and access log information that resides on the administrative server.

Malicious WSP OMS Personnel

User-specific data resident on the administrative server is vulnerable to malicious WSP OMS personnel who exploit their system access to gain access to user-specific data.

Malicious App Developer

User-specific data resident on the administrative server is vulnerable to malicious app developers who include back doors or Trojan Horse utilities or programs that the service provider uses. These app developers then use the privileged access available to their legitimate applications to obtain illegitimate access to user-specific data.

Malicious App Support Personnel

User-specific data is vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the administrative server software that disable security mechanisms.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, leaving the user-specific data vulnerable on the administrative server.

Malicious User

User-specific data resident on the administrative server is vulnerable to malicious users' gaining access to the service provider's network and thereby accessing user-specific data. The service provider's network access may be obtained by these malicious users' acting in one of the preceding roles or exploiting a vulnerability in the overall service provider's system.

Corporate Proprietary Data and Resources

Corporate proprietary data and resources refer to information resident on the administrative server that provides network details, fraud detection scheme information, and the like.

Malicious WSP OMS Personnel

Corporate proprietary data and resources resident on the administrative server are vulnerable to malicious WSP OMS personnel who exploit their system access to gain access to corporate proprietary data and resources.

Malicious App Developer

Corporate proprietary data and resources resident on the administrative server are vulnerable to malicious app developers who include back doors or Trojan Horse utilities or programs that the service provider uses. These app developers can then use the privileged access available to their legitimate applications to obtain illegitimate access to corporate proprietary data and resources.

Malicious App Support Personnel

Corporate proprietary data and resources are vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the software that disable security mechanisms present in the network server.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, leaving corporate proprietary data and resources vulnerable on the network server.

Malicious User

Corporate proprietary data and resources resident on the administrative server are vulnerable to malicious users gaining access to the service provider's network, and thereby access to corporate proprietary data and resources. The service provider's network access may be obtained by these malicious users' acting in one of the preceding roles or exploiting a vulnerability in the overall service provider's system.

Network Server
User-Specific Data

User-specific data is information such as credit card numbers, addresses, and data such as e-mail and Web traffic that transits the network server.

Malicious WSP OMS Personnel

User-specific data transiting the network server is vulnerable to malicious WSP OMS personnel who have access to the network server.

Malicious App Developer

Malicious application developers can create virus or Trojan Horse utilities or programs that cause the transit data to be vulnerable. An example would be a network routing utility containing code that routes a copy of the transit data to the app developer.

Poor or inexperienced application developers may not take appropriate security measures regarding their particular application, rendering user data vulnerable during transit.

Malicious App Support Personnel

User-specific data is vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the software that disable security mechanisms present in the network server.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, leaving the user data vulnerable during transit of the network server.

Malicious User

User-specific data is vulnerable to a malicious user who has access to, or has assumed one of the preceding roles to get access to, the network server.

Corporate Proprietary Data and Resources

Much the same as for the administrative server, corporate proprietary data and resources refer to information resident on the network server. We are referring to the system that connects the service provider's transceivers to the remainder of the wired world.

Malicious WSP OMS Personnel

Corporate proprietary data and resources resident on the network server are vulnerable to malicious WSP OMS personnel who exploit their system access to gain access to corporate proprietary data and resources.

Malicious App Developer

Corporate proprietary data and resources resident on the administrative server are vulnerable to malicious app developers who include back doors or Trojan Horse utilities or programs that the service provider uses. These app developers can then use the privileged access available to their legitimate applications to obtain illegitimate access to corporate proprietary data and resources.

Malicious App Support Personnel

Corporate proprietary data and resources are vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the software that disable security mechanisms present in the network server.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, leaving corporate proprietary data and resources vulnerable on the network server.

Malicious User

Corporate proprietary data and resources resident on the administrative server are vulnerable to malicious users gaining access to the service provider's network, and thereby access to corporate proprietary data and resources. The service provider's network access can be obtained by these malicious users' acting in one of the preceding roles or exploiting a vulnerability in the overall service provider's system.

Vulnerabilities of the Gateway

The gateway is functionally not much more than a server that performs processing to convert Web traffic to a form compatible with the wireless device. You will notice that the vulnerabilities listed mirror those for the administrative and network servers. The Web server and backend server also have similar vulnerabilities. Therefore, we will not cover the vulnerabilities for the Web server and backend server. Further, no additional vulnerability is associated with having those servers linked to a wireless system (with the exception of no longer needing physical access) than to a totally wired system.

The Physical Gateway
Malicious OMS Personnel

The gateway is vulnerable to manipulation or modification by malicious OMS personnel.

Malicious App Developer

The gateway is vulnerable to malicious app developers who include back doors or Trojan Horse utilities or programs that the gateway uses. These app developers can then use the privileged access available to their legitimate applications to obtain illegitimate access to gateway services.

Malicious App Support Personnel

The gateway is vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the software that disable security mechanisms present in the gateway.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, leaving the gateway vulnerable.

Malicious User

The gateway is vulnerable to manipulation or modification by a malicious user who has assumed one of the preceding roles or has otherwise gained access to the gateway.

User-Specific Data
Malicious OMS Personnel

User-specific data transiting or resident on the gateway is vulnerable to malicious WSP OMS personnel who have access to the network server.

Malicious App Developer

Malicious application developers can create virus or Trojan Horse utilities or programs that cause the user-specific data to be vulnerable.

Poor or inexperienced application developers may not take appropriate security measures regarding their particular application, rendering user-specific data vulnerable during transit or storage on the gateway.

Malicious App Support Personnel

User-specific data is vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the gateway software that disable security mechanisms.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, rendering the user-specific data vulnerable during transit or storage on the gateway.

Malicious User

User-specific data is vulnerable to a malicious user who has access to, or has assumed one of the preceding roles to get access to, the gateway.

User Data
Malicious OMS Personnel

User data transiting the gateway is vulnerable to malicious OMS personnel who have access to the gateway.

Malicious App Developer

Malicious application developers can create virus or Trojan Horse utilities or programs that cause the user data to be vulnerable.

Poor or inexperienced application developers may not take appropriate security measures regarding their particular application, rendering user data vulnerable during transit of the gateway.

Malicious App Support Personnel

User data is vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the gateway software that disable security mechanisms.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, rendering the user data vulnerable during transit of the gateway.

Malicious User

User data is vulnerable to a malicious user who has access to, or has assumed one of the preceding roles to get access to, the gateway.

Corporate Proprietary Data and Resources
Malicious OMS Personnel

Corporate proprietary data and resources on the gateway are vulnerable to malicious OMS personnel who have access to the gateway.

Malicious App Developer

Malicious application developers can create virus or Trojan Horse utilities or programs that cause the corporate proprietary data and resources to be vulnerable.

Poor or inexperienced application developers may not take appropriate security measures regarding their particular application, leaving corporate proprietary data and resources vulnerable on the gateway.

Malicious App Support Personnel

Corporate proprietary data and resources are vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the gateway software that disable security mechanisms.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, rendering the corporate proprietary data and resources accessible from the gateway vulnerable.

Malicious User

Corporate proprietary data and resources are vulnerable to a malicious user who has access to, or has assumed one of the preceding roles to get access to, the gateway.

Third-Party Data Transiting the Gateway
Malicious OMS Personnel

Third-party data transiting or resident on the gateway is vulnerable to malicious OMS personnel who have access to the gateway.

Malicious App Developer

Malicious application developers can create virus or Trojan Horse utilities or programs that cause third-party data to be vulnerable.

Poor or inexperienced application developers may not take appropriate security measures regarding their particular application, rendering third-party data vulnerable during transit or storage on the gateway.

Malicious App Support Personnel

Third-party data is vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the gateway software that disable security mechanisms.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, rendering third-party data vulnerable during transit or storage on the gateway.

Malicious User

Third-party data is vulnerable to a malicious user who has access to, or has assumed one of the preceding roles to get access to, the gateway.

Vulnerabilities of the Web Server and the Backend Server

The Web server and backend server have nearly identical vulnerabilities as those identified for the gateway. Because we are concentrating on the wireless aspects of security, we will not explicitly go through the exercise of listing the vulnerabilities of these two functional blocks. Keep in mind that although the vulnerabilities may be identical, the protections or mitigations chosen can differ considerably because of the analysis of likelihood and the functionality trade-offs considered.

It should be clear that when you have identified the targets and roles, stating the vulnerabilities becomes simple. It should also be obvious how these vulnerability statements can be easily modified to become requirement statements.


Chapter 11. Analyze Mitigations and Protections

Victory goes to the player who makes the next-to-last mistake.

—Chessmaster Savielly Grigorievitch Tartakower (1887–1956)

Now that you have established a knowledge base, it is time to continue the I-ADD process. In review, you divide the system into its functional blocks. You then examine each of these blocks to determine the potential targets of interest to an attacker. These blocks are then broken down to their functional subcomponents, and the process is repeated until the lowest functional blocks are identified and analyzed.

Next, you examine the targets and identify the roles that have influence over the targets. You identify known attacks against similar systems and determine your system's vulnerabilities, based on examining the targets and roles. As discussed in Chapter 2 , "Security Principles," the goal of this analysis phase is to develop an understanding of which items deserve additional resources to protect, which items are "nice to have," and which can be placed on an "acknowledged with no action necessary" list.

You begin the process of generating mitigations and protections by examining each vulnerability and determining the appropriate solution for protecting or mitigating the risk this vulnerability imposes on the system. The key here is the word appropriate; there can be many ways of mitigating the risk introduced by a vulnerability. This is where a security expert can save a lot of time and resources in helping to identify what is an appropriate solution and what is not. Should you decide to perform this analysis on your own, you must be cautious that solutions identified to mitigate one risk do not generate other vulnerabilities. Repeating the I-ADD process on the system with the mitigations in place is one way to accomplish this.

We shall now examine each vulnerability previously identified and discuss possible ways of mitigating or protecting it from attack. Because this is a hypothetical system and we have identified quite a few vulnerabilities, we will cover aspects with wider applicability in more detail. Other vulnerabilities will be covered only briefly. Again, the purpose is to give you guidance on how to go about analyzing or performing this type of analysis on your own particular system or component. Keep in mind that having multilevel protection adds significantly to a system's overall security. Further, you are not necessarily making implementation or functional trade-offs at this time. However, it does little good to list solutions that are impractical, such as "Assign two heavily armed guards to protect the device from theft." In general, attackers look for areas where their efforts will have the greatest payoff, areas with only a single protection mechanism to bypass or with known vulnerabilities.


Protecting the Wireless Device

Two approaches can be taken to mitigate the risk of loss or theft, depending on your concern. Are you concerned about someone gaining access to the information or services provided by the device? Are you concerned that you may not have access to the information or resources if you misplace or lose the device? Let's examine loss and theft separately.

Limiting the Vulnerability to Loss

The device could be made smaller so that it is easier to keep on one's person. However, a smaller device is easier to misplace. A wearable device is easier to keep track of and less likely to be misplaced than a device not worn by the user.

The device could have a holster or carrying case. For example, belt holsters are common with cell phones and PDAs. These holsters are fine for men, but women do not usually want to wear these devices. Women are forced to carry the device in their purse, backpack, or bag.

Extending the preceding case, a wearable interface is better than a wearable device. The interface would be smaller, less intrusive, and possibly more widely accepted by both male and female users. An example would be a heads-up PDA display of the screen on the user's glasses or sunglasses; the input portion could be worn like a watch. The main device could be kept in a purse or worn on a holster. When the device is moved outside communications range of the remote interface devices, an alarm would sound to alert the user.

A second suggestion is a voice-activated phone. Only the microphone and the earpiece would be worn. The microphone could look like a lapel pin. The earpiece could look like earrings or be small enough to fit within the ear canal, similar to digital hearing aids. Being voice activated, there would be no need for a keypad.

The device could be equipped with some type of proximity sensors. These sensors would come in pairs, one sensor worn like a ring or bracelet and the other within the device. If the two became separated beyond the range of the sensors, one or both would alarm to notify the user of the separation and the device's location.

The device could be made to be the access mechanism for applications and data stored on a server somewhere. The device itself would simply be the interface and, as such, would be inexpensive. Its loss would be inconsequential.

Limiting the Vulnerability to Theft

The protections described for loss apply as well to theft. However, with the exception of the last protection, they are aimed at notifying the user of the theft and not at deterring the theft. In general, theft occurs when the thief perceives value in having the device—from selling or using the device or by using the information contained on the device. With this in mind, you should consider the following protections or mitigations.

The device could be made inexpensive and readily available. Charge for service rather than for the device. If the device's value drops below a certain threshold, taking it will not be worth a thief's effort.

The device could be configured as tiny wearable components that would be difficult for a thief to obtain.

The device could require an external authentication mechanism, such as a SmartCard or proximity device, to enable it. For the device to be useful, a thief would have to take the device and the enabling token. The enabling device, being smaller, could be better protected on one's person when not in use.

The device could be made so that it is useful only to the owner. Employing a form of biometric authentication to access the device would do this. One scenario would be to have the device personalized when it is purchased. This would be a one-time, nonreversible activity that would link the device and user; only the user could access the device. Biometric authentication, such as a fingerprint, retinal scans, a voiceprint, or even DNA analysis, would eliminate the threat of random theft. Other issues could be associated with this solution, such as user acceptance and processing power limitations.


Protecting the Physical Interface

Protecting physical access to the device is instrumental in your system. Restricting access to something that is mobile, not stationary, is tricky. To minimize potential damage caused by unauthorized physical access, attention should be paid to developing code governing the user interface and all data stored on the device. By designing protection mechanisms inside the device, you can prepare for worst-case scenarios of unauthorized and malicious physical access.

Protecting Access to the User Interface

We will not cover this vulnerability in great detail because it is being addressed by the manufacturers. They are making strides to mitigate this risk by providing protective cases, flip-up covers, and impervious membranes, locking the keyboard/keypad, and rugged-izing cases.

Protecting Personal Data on the PDA

We will examine the protection of personal data by looking at the various roles identified, similar to the approach we took in identifying the vulnerabilities. We also restate the vulnerability so that you do not have to refer to Chapter 6 , "Cryptography." This approach need not be taken with every vulnerability, but it helps ensure completeness.

Malicious Device Support Personnel

Personal data stored on the device can be vulnerable to malicious device support personnel when the device is taken in for upgrades, maintenance, or repair. These support personnel may have access to manufacturer bypass and diagnostic codes, equipment, or utilities that allow them access to personal data stored on the device.

Poor or inexperienced device support personnel may inadvertently leave the device in a security bypass or diagnostic mode, leaving personal data vulnerable.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access. By rotating team members, alliances that encourage malicious activity are less likely to form.

· An alternative to teams would be video monitoring of work areas. Security or managerial personnel monitor support activities to ensure the device's integrity.

· Institute a checklist and an oversight procedure for processing devices that are in for support, to ensure that all security bypass or diagnostic modes have been properly reset to operational settings. This prevents poor or inexperienced personnel from inadvertently leaving the device vulnerable.

· Make the personal data inaccessible even if someone does have privileged access. This can be accomplished by storing all personal data on the device in encrypted form. As long as the encryption is cryptographically sound, it will be extremely difficult for someone to obtain useful personal information from the device.

· Following on the preceding track of making the personal data inaccessible, store all personal data on a removable device such as a SmartCard. The SmartCard provides authentication before allowing access to the personal data. Also, the SmartCard can directly communicate the personal information (such as a credit card number) with the application requiring the information.

· Price the device so that obtaining a new one is more cost-effective than repairing the old unit.

Malicious App Developer

Malicious application developers can create a virus or Trojan Horse utilities or programs that provide access to personal data on the PDA.

Poor or inexperienced application developers may not take appropriate security measures regarding their particular application (such as not clearing buffers and overwriting data elements), leaving personal data stored on the device vulnerable.

· Institute a certification program, enforced by the OS, allowing only digitally signed code from authorized certifiers to be loaded on the device. This would require that the software be examined by the device manufacturer or an independent third party to validate that the software is secure and reliable and functions as advertised. This certification would also digitally sign the code to ensure the code's (and certificate's) authenticity and integrity.

· Implement a trusted OS on the device that establishes virtual environments for programs. The program believes that it has complete and direct access to the device's resources, but the OS continually monitors and processes the requests on the program's behalf. In this way, should the program attempt to do something untoward, the OS can simply return an error or otherwise keep the activity from occurring.

· Have the device perform a hardware resident integrity check of the device and the OS to ensure that the device's integrity is intact before initializing the system. (This is a result of the preceding protection and can be implied from the term trusted OS, but we specifically choose to list this separately because it has other uses.)

Malicious App Support Personnel

Malicious application support personnel may coerce the user via social engineering to provide access, or information necessary for access, to personal data under the auspices of assisting with an application issue. Alternatively, malicious app support personnel may enable debug or other diagnostic switches within the software that disable security mechanisms present in the device or software.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled following a support activity, leaving the personal data vulnerable.

Interestingly enough, and logically, the protections applicable for this role are a combination of the protections for the malicious device support personnel and malicious app developer.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Institute a checklist and an oversight procedure for processing devices that are in for support, to ensure that all security bypass or diagnostic modes have been properly reset to operational settings.

· Store all personal data on the device in encrypted form. As long as the encryption is cryptographically sound, it will be extremely difficult for someone to obtain useful personal information from the device.

· Store all personal data on a removable device, such as a SmartCard. The SmartCard provides authentication before allowing access to the personal data.

· Institute a certification program, enforced by the OS, allowing only digitally signed code from authorized certifiers to be loaded on the device. This would require that the software be examined by the device manufacturer or an independent third party to validate that the software is secure and reliable and functions as advertised. This certification would also digitally sign the code to ensure the code's (and certificate's) authenticity and integrity.

· Implement a trusted OS on the device that establishes virtual environments for programs. The program believes that it has complete and direct access to the device's resources, but the OS continually monitors and processes the requests on the program's behalf. In this way, should the program attempt to do something untoward, the OS can simply return an error or otherwise keep the activity from occurring.

· Have the device perform a hardware resident integrity check of the device and the OS to ensure that the device's integrity is intact before initializing the system.

Malicious User

Personal data is vulnerable to a malicious user who has gained access to the device. Recall that malicious user is a catchall term encompassing a variety of activities. Although this simple statement is adequate for describing the vulnerability, the complexity of the role may become important when generating mitigations and protections or performing the security-functionality trade-offs, and it should not be forgotten. For example, a malicious user may pose as a member of one of the legitimate functional roles and become the functional equivalent of one of the preceding, listed malicious roles.

Because the malicious user may pose as a member of one of the legitimate functional roles and become the functional equivalent of one of the preceding, listed malicious roles, each of the preceding protections applies here as well. Therefore, we list only protections not previously covered in the other roles:

· Shield the device from physical and nonphysical technical attacks against memory, data emanation, power analysis, and the like. Most of these issues are beyond the scope of this book, so suffice it to say that if these types of issues are of concern in your particular application or architecture, you have to become involved with the manufacturer to determine the susceptibility of a given component or device to such attacks.

· Make the device hardware tamper-proof by not allowing the case to be opened without destroying or clearing the memory.

· Have the device perform a hardware resident integrity check of the device and the OS to ensure that the device's integrity is intact before initializing the system.

Protecting Corporate or Third-Party Information

From a vulnerability perspective, no distinction exists between corporate or third-party information and personal data. There may be some distinction when it comes to the security-functionality trade-offs.

Protections also indicate no distinction between corporate or third-party information and personal data.

Protecting Personal Data Being Sent by the Wireless Device

This target is the personal data mentioned in the preceding section, but here the target is the data as it is in transit. You will notice that all the preceding roles are present, with the addition of a few others due to the increased exposure of the data during transport.

Malicious Wireless Service Provider (WSP)

Recall the office complex case study example in Chapter 9 , " Identify Targets and Roles ," in which a company provides gratis access to a client, only to monitor the client's activities.

· Encrypt the data to be transmitted so that only the desired recipient can decrypt it.

Malicious Device Support Personnel

Personal data transmitted by the device may be made vulnerable by malicious device support personnel when the device is taken in for upgrades, maintenance, or repair. These support personnel may have access to manufacturer bypass and diagnostic codes, equipment, or utilities that allow them to intentionally bypass security features, leaving personal data transmitted by the device vulnerable.

Poor or inexperienced device support personnel may inadvertently leave the device in a security bypass or diagnostic mode, making personal data vulnerable during transit.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Institute a checklist and an oversight procedure for processing devices that are in for support, to ensure that all security bypass or diagnostic modes have been properly reset to operational settings.

· Encrypt the data to be transmitted so that only the desired recipient can decrypt it.

· Have the device perform a hardware resident integrity check of the device and the OS to ensure that the device's integrity is intact before initializing the system. This ensures that critical procedures such as the encryption applications have not been disabled or tampered with.

· Price the device so that obtaining a new one is more cost-effective than repairing the old unit.

Malicious WSP OMS Personnel

Personal data transmitted by the device is vulnerable to malicious WSP OMS personnel who have access to the WSP transceiver and wireless network equipment.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Encrypt the data to be transmitted so that only the desired recipient can decrypt it.

Malicious App Developer

Malicious application developers may create a virus or Trojan Horse utilities or programs that cause the transmitted data to be vulnerable. An example would be an encryption utility containing nonunique or known keys. To the user, the data appears encrypted, but it is readily accessible to unauthorized individuals who know the key. Alternatively, an e-mail utility may send a blind copy of every message sent or received by the device to a predefined address.

Poor or inexperienced application developers may not take appropriate security measures regarding their particular application, leaving personal data vulnerable during transit.

· Institute a certification program, enforced by the OS, allowing only digitally signed code from authorized certifiers to be loaded on the device. This requires that the software be examined by the device manufacturer or an independent third party to validate that the software is secure and reliable and functions as advertised. This certification would also digitally sign the code to ensure the code's (and certificate's) authenticity and integrity.

· Implement a trusted OS on the device that establishes virtual environments for programs. The program believes that it has complete and direct access to the device's resources, but the OS continually monitors and processes the requests on the program's behalf. In this way, should the program attempt to do something untoward, the OS can simply return an error or otherwise keep the activity from occurring.

· Have the device perform a hardware resident integrity check of the device, OS, and critical software to ensure that the device's integrity is intact before initializing the system.

· Store all personal data on the device in encrypted form.

· Store all personal data on a removable device such as a SmartCard. The SmartCard provides authentication before allowing access to the personal data. Have the SmartCard perform the communication activity itself so that the device is merely a conduit.

· Encrypt the data to be transmitted so that only the desired recipient can decrypt it.

Malicious App Support Personnel

Malicious application support personnel may coerce the user via social engineering to provide access, or information necessary for access, to personal data under the auspices of assisting with an application issue. Alternatively, malicious app support personnel may enable debug or other diagnostic switches within the software that disable security mechanisms present in the device or software.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, leaving the personal data vulnerable during transit.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Institute a checklist and an oversight procedure for processing devices that are in for support, to ensure that all security bypass or diagnostic modes have been properly reset to operational settings.

· Store all personal data on the device in encrypted form.

· Store all personal data on a removable device such as a SmartCard. The SmartCard provides authentication before allowing access to the personal data. Have the SmartCard perform the communication activity itself so that the device is merely a conduit.

· Institute a certification program, enforced by the OS, allowing only digitally signed code from authorized certifiers to be loaded on the device. This would require that the software be examined by the device manufacturer or an independent third party to validate that the software is secure and reliable and functions as advertised. This certification would also digitally sign the code to ensure the code's (and certificate's) authenticity and integrity.

· Implement a trusted OS on the device that establishes virtual environments for programs. The program believes that it has complete and direct access to the device's resources, but the OS continually monitors and processes the requests on the program's behalf. In this way, should the program attempt to do something untoward, the OS can simply return an error or otherwise keep the activity from occurring.

· Have the device perform a hardware resident integrity check of the device and the OS to ensure that the device's integrity is intact before initializing the system.

· Encrypt the data to be transmitted so that only the desired recipient can decrypt it.

Malicious User

Personal data is vulnerable to a malicious user who has access to, or has built a receiver that monitors, the transmission of the PDA and can reconstruct the data transmitted and received. Again, a malicious user may assume any of the preceding malicious roles to gain access necessary to exploit a vulnerability.

All the protections for the preceding roles apply here.

Protecting Corporate or Third-Party Information Being Sent

As with offline functions, from a vulnerability perspective there is no distinction between corporate or third-party information and personal data in transit.

Protections also indicate no distinction between corporate or third-party information and personal data being sent.

Protecting User Online Activities, Usage Patterns, Location, and Movement

This category can be considered a subset of or equivalent to user personal data as far as vulnerabilities are concerned.

Protection of user online activities, usage patterns, location, and movement can be treated as personal data if and while it is stored on the device. In this situation, the protections for personal data on the device apply. Now, consider protecting this information during transit—a different problem altogether. The difficulty is that the wired Internet was not originally designed with security and privacy in mind. In fact, quite the opposite, it was designed as an open and available architecture for freely sharing ideas and data. Only recently, with the desire to commercialize the Internet, has the need for security and privacy become important. The requirement is to protect user information traveling on an open and accessible infrastructure.

· Encryption is the first thing that comes to mind. One solution is that you do not transmit in unencrypted form any information that specifically identifies the user. This would likely require the cooperation of application developers. Applications would have to be capable of accepting user-specific information in encrypted form. This is not as easy as it sounds. The use of encryption protects the information communicated but not the fact that the communication is occurring. To protect the user's privacy, an unauthorized party should not be able to determine that the user communicated with the server.

· Have the WSP act as a proxy server for all activity so that malicious individuals see only that a wireless user is involved. The WSP performs the routing of packets to the true user. This places a lot of additional processing burden on the WSP, and although it would solve the dilemma of providing privacy, it is unlikely that WSPs will provide this service unless consumers begin to refuse to accept service without privacy. It is the classic "We can forgo the security because consumers will demand the functionality and will give up security to get it."

Protecting Access to Network and Online Services

As used here, access to network and online services means the use of the device or information on the device to gain access to network and online services. This distinction separates it from similar activities occurring against the service provider, which we will discuss shortly.

Malicious Device Support Personnel

User network and online services access credentials are vulnerable to device support personnel who have access to the device for upgrade, maintenance, or repair purposes. Device support personnel may have access to manufacturer bypass and diagnostic codes, equipment, or utilities that give them access to network and online service access credentials on the device.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Utilize video monitoring of work areas so that security or managerial personnel can monitor support activities to ensure the device's integrity.

· Encrypt the credentials stored on the device, and transmit the credentials and access code in encrypted form so that only the desired recipient can decrypt the data.

· The network or online services could require some form of biometric or SmartCard authentication so that the information on the device itself is insufficient to gain access to the resources.

· Price the device so that obtaining a new one is more cost-effective than repairing the old unit.

Malicious WSP OMS Personnel

User network and online services access credentials are vulnerable to WSP OMS personnel when this information is received and processed by the WSP equipment. The user may also be coerced into providing network or online access credentials to WSP OMS personnel.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Implement access control and logging systems to monitor OMS personnel access to sensitive equipment and areas.

Note

Logging is beneficial only if someone examines the logs. To derive the greatest benefit from logs, they should be examined by an automated process that detects anomalies or alert conditions and sends notification to the appropriate authority.

· Utilize video monitoring of critical areas so that security or managerial personnel can monitor support activities to ensure the system's integrity.

· Encrypt the credentials stored on the device, and transmit the credentials and access code in encrypted form so that only the desired recipient can decrypt the data.

· The network or online services could require a form of biometric or SmartCard authentication so that obtaining the information on the device itself is insufficient to gain access to the resources.

Malicious App Developer

User network and online services access credentials are vulnerable to applications that can copy and store, or forward, these credentials to the developer.

· Encrypt the credentials stored on the device, and transmit the credentials and access code in encrypted form so that only the desired recipient can decrypt the data.

· The network or online services could require a form of biometric or SmartCard authentication so that obtaining the information on the device itself is insufficient to gain access to the resources.

Malicious User

Access to network and online services are vulnerable to a malicious user. A malicious user may gain access to the device and retrieve network and online services credentials to be used on another device or at a later time. A malicious user may monitor transmissions (as discussed in the " Malicious User " section under " Protecting Personal Data Being Sent by the Wireless Device ") to obtain network and online services credentials. Again, a malicious user may assume any of the preceding malicious roles to gain access necessary to exploit a vulnerability.

All the protections for the preceding roles apply here.

Protecting the Transceiver

Protecting the Transceiver Itself
Malicious Device OMS Personnel

The transceiver is vulnerable to manipulation or modification by malicious device OMS personnel.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Have all maintenance and support activities reviewed by a Quality Assurance/Security team where the transceiver is tested and inspected.

· Utilize video monitoring of work areas so that security or managerial personnel can monitor support activities to ensure the device's integrity.

· Make the transceiver a nonservicable, tamper-proof component that is replaced as a unit if it fails.

· Price the device so that obtaining a new one is more cost-effective than repairing the old unit.

Malicious User

The transceiver is vulnerable to manipulation or modification by a malicious user. For example, manipulating the transceiver can be done to assist a man-in-the-middle attack.

· Make the transceiver a nonservicable, tamper-proof component that is replaced as a unit if it fails.

Protecting Vulnerabilities of the Service Provider

Protecting the Transceiver Itself

When we use the term transceiver in regard to the service provider, we are considering the transceiver system as consisting of the antenna array, tower, coax, transceiver, and switching equipment.

Malicious WSP OMS Personnel

The transceiver is vulnerable to manipulation or modification by malicious WSP OMS personnel.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Implement access control and logging systems to monitor OMS personnel access to sensitive equipment and areas.

· Have all maintenance and support activities reviewed by a Quality Assurance/Security team where the transceiver is tested and inspected.

· Utilize video monitoring of work areas so that security or managerial personnel can monitor support activities to ensure the transceiver's integrity.

Malicious User

The transceiver is vulnerable to manipulation or modification by a malicious user. For example, this may be done to deny service to areas or individuals at crucial times.

· Implement access control and logging systems to monitor OMS personnel access to sensitive equipment and areas.

· Utilize video monitoring of work areas so that security or managerial personnel can monitor support activities to ensure the transceiver's integrity.

Protecting the Transceiver Services

Malicious WSP OMS Personnel

The transceiver services are vulnerable to manipulation or modification by malicious WSP OMS personnel, for example, granting access to the network to unauthorized users by providing them with maintenance or diagnostic access credentials.

· Implement access control and logging systems to monitor OMS personnel access to network and sensitive areas.

· Require the use of biometric SmartCard authentication or another physical access token, in addition to any maintenance or diagnostic access credentials.

Malicious User

The transceiver is vulnerable to manipulation or modification by a malicious user. For example, a malicious user may obtain access credentials to utilize the service without paying for the privilege.

· Implement access control and logging systems to monitor OMS personnel access to sensitive equipment and areas.

· Utilize video monitoring of work areas so that security or managerial personnel can monitor support activities to ensure the transceiver's integrity.

· Require the use of biometric SmartCard authentication or another physical access token, in addition to any maintenance or diagnostic access credentials.

Protecting Access to Its Subscribers

Malicious WSP OMS Personnel

The service provider is vulnerable to WSP OMS personnel who grant access to the network and thereby its subscribers for spam or other unsolicited purposes.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Implement access control and logging systems to monitor OMS personnel access to sensitive equipment and areas.

· Have all maintenance and support activities reviewed by a Quality Assurance/Security team where the transceiver is tested and inspected.

· Utilize video monitoring of work areas so that security or managerial personnel can monitor support activities to ensure the integrity of the service provider's system.

Malicious Corporate and Private Servers

The service provider is vulnerable to malicious corporate or private servers that access the service provider to deliver advertising, marketing, or other spam to the service provider's subscribers.

· Do not allow subscriber information to become available to outside servers.

· Maintain subscriber information on a separate server, and require authentication for processes or entities requesting access to this server.

· Store subscriber information in encrypted form.

· Establish a firewall/proxy server so that details of the network are not available to external entities.

· Do not allow nonspecifically addressed messages to be processed by the system.

· Implement access control and logging systems to monitor access to equipment and resources.

Malicious Corporate and Private Server OMS Personnel

The service provider is vulnerable to malicious corporate or private server OMS personnel who utilize authorized servers to allow unauthorized access to subscribers. For example, a service provider's subscribers receive stock quotes as part of their service plan. OMS personnel with access to the quote server that provides this service can alter the server to deliver anything in addition to, or in place of, the stock quotes.

· Implement access control and logging systems to monitor access to equipment and resources. Prohibiting this type of abuse is problematic because the attacker is taking advantage of an authorized capability. The best the service provider can do is to have logs in place that identify this activity and report it to the server's security or administrative personnel. Alternatively, the service provider can deny any further access by that particular server or company.

Malicious Content Providers

The service provider is vulnerable to malicious content providers who use the service provider's resources to spam or otherwise deliver their payload to the subscribers.

· Do not allow subscriber information to become available to outside servers.

- Maintain subscriber information on a separate server, and require authentication for processes or entities requesting access to this server.

- Store subscriber information in encrypted form.

- Establish a firewall/proxy server so that details of the network are not available to external entities.

· Do not allow nonspecifically addressed messages to be processed by the system.

· Implement access control and logging systems to monitor access to equipment and resources.

Malicious App Developer

The service provider is vulnerable to malicious app developers who include back doors or Trojan Horse utilities or programs that the service provider uses. These app developers can then use the privileged access available to their legitimate applications to obtain illegitimate access to the subscribers.

· Institute a certification program, enforced by the OS, allowing only digitally signed code from authorized certifiers to be loaded on the service provider's systems. This would require that the software be examined by the service provider or an independent third party to validate that the software is secure and reliable and functions as advertised. This certification would also digitally sign the code to ensure the code's (and certificate's) authenticity and integrity.

· Implement a trusted OS on the service provider's systems that establishes virtual environments for programs. The program believes that it has complete and direct access to the service provider's resources, but the OS continually monitors and processes the requests on the program's behalf. In this way, should the program attempt to do something untoward, the OS can simply return an error or otherwise keep the activity from occurring.

· Have the information systems perform a hardware resident integrity check of the system, OS, and critical software to ensure that the system's integrity is intact before initializing the system.

· Store all subscriber data on the system in encrypted form.

· Require authentication before allowing access to subscriber data. Have the access and activity on the system logged.

Malicious App Support Personnel

Service provider subscribers are vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the software that disable security mechanisms present to protect access to the service provider's subscribers.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, leaving corporate proprietary data and resources vulnerable on the network server.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Institute a checklist and an oversight procedure for app support activities to ensure that all security bypass or diagnostic modes have been properly reset to operational settings.

· Store all subscriber data on the system in encrypted form.

· Institute a certification program, enforced by the OS, allowing only digitally signed code from authorized certifiers to be loaded on the system. This would require that the software be examined by the service provider or an independent third party to validate that the software is secure and reliable and functions as advertised. This certification would also digitally sign the code to ensure the code's (and certificate's) authenticity and integrity.

· Implement a trusted OS on the service provider's systems that establishes virtual environments for programs. The program believes that it has complete and direct access to the service provider's resources, but the OS continually monitors and processes the requests on the program's behalf. In this way, should the program attempt to do something untoward, the OS can simply return an error or otherwise keep the activity from occurring.

· Have the information systems perform a hardware resident integrity check of the system, OS, and critical software to ensure that the system's integrity is intact before initializing the system.

· Implement access control and logging systems to monitor access to equipment and resources.

Malicious User

The service provider is vulnerable to malicious users' gaining access to its network to allow them access to the service provider's subscribers, either by acting in one of the preceding roles or by exploiting a vulnerability in the service provider's overall system.

All the protections for the preceding roles apply here.

· Continually monitor bug and vulnerability reports of software and information systems in use to ensure that new vulnerabilities and exploits are properly mitigated in a timely fashion.

· Periodically perform security risk analysis of the system to ensure that something has not been overlooked or some change or update to one part of the system has not left another part vulnerable to exploitation.

Protecting the Transceiver

Recall that there are no additional targets for the transceiver beyond those identified for the higher-level functional block. Likewise, there would likely not be any additional protections or mitigations to identify.

Protecting the Administrative Server

By administrative server, we are referring to the billing, maintenance, and support systems associated with keeping the wireless infrastructure functional.

Protecting User-Specific Data

User-specific data is information such as credit card numbers, addresses, finances, call and access log information that resides on the administrative server.

Malicious WSP OMS Personnel

User-specific data resident on the administrative server is vulnerable to malicious WSP OMS personnel who exploit their system access to gain access to user-specific data.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Implement access control and logging systems to monitor OMS personnel access to sensitive equipment and areas.

· Have all maintenance and support activities reviewed by a Quality Assurance/Security team. This should include logs of system and information access associated with the support activity.

· Utilize video monitoring of work areas so that security or managerial personnel can monitor support activities to ensure the system's integrity.

Malicious App Developer

User-specific data resident on the administrative server is vulnerable to malicious app developers who include back doors or Trojan Horse utilities or programs that the service provider uses. These app developers can then use the privileged access available to their legitimate applications to obtain illegitimate access to user-specific data.

· Institute a certification program, enforced by the OS, allowing only digitally signed code from authorized certifiers to be loaded on the system. This would require that the software be examined by the service provider or an independent third party to validate that the software is secure and reliable and functions as advertised. This certification would also digitally sign the code to ensure the code's (and certificate's) authenticity and integrity.

· Implement a trusted OS on the administrative server that establishes virtual environments for programs. The program believes that it has complete and direct access to the administrative server's resources, but the OS continually monitors and processes the requests on the program's behalf. In this way, should the program attempt to do something untoward, the OS can simply return an error or otherwise keep the activity from occurring.

· Have the administrative server perform a hardware resident integrity check of the system, OS, and critical software to ensure that the system's integrity is intact before initializing the system.

· Store all user-specific data on the system in encrypted form.

· Require authentication before allowing access to user-specific data.

· Have the access and activity on the system logged.

· Require the use of a physical token as part of the authentication process.

Malicious App Support Personnel

User-specific data is vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the administrative server software that disable security mechanisms.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, leaving the user-specific data vulnerable on the administrative server.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Institute a checklist and an oversight procedure for processing app support activities to ensure that all security bypass or diagnostic modes have been properly reset to operational settings.

· Store all user-specific data on the system in encrypted form.

· Institute a certification program, enforced by the OS, allowing only digitally signed code from authorized certifiers to be loaded on the system. This would require that the software be examined by the service provider or an independent third party to validate that the software is secure and reliable and functions as advertised. This certification would also digitally sign the code to ensure the code's (and certificate's) authenticity and integrity.

· Implement a trusted OS on the service provider's systems that establishes virtual environments for programs. The program believes that it has complete and direct access to the service provider's resources, but the OS continually monitors and processes the requests on the program's behalf. In this way, should the program attempt to do something untoward, the OS can simply return an error or otherwise keep the activity from occurring.

· Have the information systems perform a hardware resident integrity check of the system, OS, and critical software to ensure that the system's integrity is intact before initializing the system.

· Implement access control and logging systems to monitor access to equipment and resources.

Malicious User

User-specific data resident on the administrative server is vulnerable to malicious users' gaining access to the service provider's network and thereby access to user-specific data. The service provider's network access can be obtained by these malicious users' acting in one of the preceding roles or exploiting a vulnerability in the service provider's overall system.

All the protections for the preceding roles apply here.

· Continually monitor bug and vulnerability reports of software and information systems in use to ensure that new vulnerabilities and exploits are properly mitigated in a timely fashion.

· Periodically perform security risk analysis of the system to ensure that something has not been overlooked or some change or update to one part of the system has not left another part vulnerable to exploitation.

Protecting Corporate Proprietary Data and Resources

Corporate proprietary data and resources refers to information resident on the administrative server that provides network details, fraud detection scheme information, and the like.

Malicious WSP OMS Personnel

Corporate proprietary data and resources resident on the administrative server are vulnerable to malicious WSP OMS personnel who exploit their system access to gain access to corporate proprietary data and resources.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Implement access control and logging systems to monitor OMS personnel access to sensitive equipment and areas.

· Have all maintenance and support activities reviewed by a Quality Assurance/Security team. This should include logs of system and information access associated with the support activity.

· Utilize video monitoring of work areas so that security or managerial personnel can monitor support activities to ensure the system's integrity.

· Store all corporate proprietary data on the system in encrypted form.

Malicious App Developer

Corporate proprietary data and resources resident on the administrative server are vulnerable to malicious app developers who include back doors or Trojan Horse utilities or programs that the service provider uses. These app developers can then use the privileged access available to their legitimate applications to obtain illegitimate access to corporate proprietary data and resources.

· Institute a certification program, enforced by the OS, allowing only digitally signed code from authorized certifiers to be loaded on the system. This would require that the software be examined by the service provider or an independent third party to validate that the software is secure and reliable and functions as advertised. This certification would also digitally sign the code to ensure the code's (and certificate's) authenticity and integrity.

· Implement a trusted OS on the administrative server that establishes virtual environments for programs. The program believes that it has complete and direct access to the administrative server's resources, but the OS continually monitors and processes the requests on the program's behalf. In this way, should the program attempt to do something untoward, the OS can simply return an error or otherwise keep the activity from occurring.

· Have the administrative server perform a hardware resident integrity check of the system, OS, and critical software to ensure that the system's integrity is intact before initializing the system.

· Store all corporate proprietary data on the system in encrypted form.

· Require authentication before allowing access to corporate proprietary data.

· Have the access and activity on the system logged.

· Require the use of a physical token as part of the authentication process.

Malicious App Support Personnel

Corporate proprietary data and resources are vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the software that disable security mechanisms present in the network server.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, leaving corporate proprietary data and resources vulnerable on the network server.

· Have all maintenance and support activities performed by maintenance teams with rotating members, rather than by individuals. This limits the opportunity for support personnel with malicious intent to exploit their privileged access.

· Institute a checklist and an oversight procedure for processing app support activities to ensure that all security bypass or diagnostic modes have been properly reset to operational settings.

· Store all corporate proprietary data on the system in encrypted form.

· Institute a certification program, enforced by the OS, allowing only digitally signed code from authorized certifiers to be loaded on the system. This would require that the software be examined by the service provider or an independent third party to validate that the software is secure and reliable and functions as advertised. This certification would also digitally sign the code to ensure the code's (and certificate's) authenticity and integrity.

· Implement a trusted OS on the service provider's systems that establishes virtual environments for programs. The program believes that it has complete and direct access to the service provider's resources, but the OS continually monitors and processes the requests on the program's behalf. In this way, should the program attempt to do something untoward, the OS can simply return an error or otherwise keep the activity from occurring.

· Have the information systems perform a hardware resident integrity check of the system, OS, and critical software to ensure that the system's integrity is intact before initializing the system.

· Implement access control and logging systems to monitor access to equipment and resources.

· Require authentication before allowing access to corporate proprietary data.

· Have the access and activity on the system logged.

· Require the use of a physical token as part of the authentication process.

Malicious User

Corporate proprietary data and resources resident on the administrative server are vulnerable to malicious users' gaining access to the service provider's network and thereby access to corporate proprietary data and resources. The service provider's network access can be obtained by these malicious users' acting in one of the preceding roles or exploiting a vulnerability in the service provider's overall system.

All the protections for the preceding roles apply here.

· Continually monitor bug and vulnerability reports of software and information systems in use to ensure that new vulnerabilities and exploits are properly mitigated in a timely fashion.

· Periodically perform security risk analysis of the system to ensure that something has not been overlooked or some change or update to one part of the system has not left another part vulnerable to exploitation.

Protecting the Network Server

Protecting User-Specific Data

User-specific data is information such as credit card numbers, addresses, and data such as e-mail and Web traffic that transits the network server.

Malicious WSP OMS Personnel

User data transiting the network server is vulnerable to malicious WSP OMS personnel who have access to the network server.

The protections here are the same as the protections employed for the administrative server.

Note

The only additional concern to consider for this role, as well as the following roles, is the potential for attacks or access via the network to which the network server is connected. Network-based attacks are not unique to wireless systems and are well publicized. Plenty of available resources cover this area of security, so we will not cover it in any detail here.

Malicious App Developer

Malicious application developers can create a virus or Trojan Horse utilities or programs that cause the transit data to be vulnerable. An example would be a network routing utility containing code that routes a copy of the transit data to the app developer.

Poor or inexperienced application developers may not take appropriate security measures regarding their particular application, leaving user data vulnerable during transit.

The protections here are the same as the protections for the administrative server.

Malicious App Support Personnel

User data is vulnerable to malicious application support personnel who can enable debug or other diagnostic switches within the software that disable security mechanisms present in the network server.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, leaving the user data vulnerable during transit of the network server.

The protections here are the same as the protections for the administrative server.

Malicious User

User data is vulnerable to a malicious user who has access, or has assumed one of the preceding roles to get access, to the network server.

The protections here are the same as the protections for the administrative server.

Protecting Corporate Proprietary Data and Resources

Much the same as for the administrative server, corporate proprietary data and resources refers to information resident on the network server. We are referring to the system that connects the service provider's transceivers to the remainder of the wired world.

Malicious WSP OMS Personnel

Corporate proprietary data and resources resident on the network server are vulnerable to malicious WSP OMS personnel who exploit their system access to gain access to corporate proprietary data and resources.

The protections here are the same as the protections for the administrative server.

Malicious App Developer

Corporate proprietary data and resources resident on the administrative server are vulnerable to malicious app developers who include back doors or Trojan Horse utilities or programs that the service provider uses. These app developers can then use the privileged access available to their legitimate applications to obtain illegitimate access to corporate proprietary data and resources.

The protections here are the same as the protections for the administrative server.

Malicious App Support Personnel

Corporate proprietary data and resources are vulnerable to malicious application support personnel who enable debug or other diagnostic switches within the software that disable security mechanisms present in the network server.

Poor or inexperienced app support personnel may inadvertently leave debug or diagnostic switches enabled at the conclusion of a support activity, leaving corporate proprietary data and resources vulnerable on the network server.

The protections here are the same as the protections for the administrative server.

Malicious User

Corporate proprietary data and resources resident on the administrative server are vulnerable to malicious users' gaining access to the service provider's network, and thereby access to corporate proprietary data and resources. The service provider's network access can be obtained by these malicious users' acting in one of the preceding roles or exploiting a vulnerability in the service provider's overall system.

The protections here are the same as the protections for the administrative server.

Protecting Vulnerabilities of the Gateway

As stated in Chapter 10 , the gateway is functionally not much more than a server that performs some processing to convert Web traffic to a form compatible with the wireless device. You will notice that vulnerabilities and protections listed for the network server mirror those for the administrative server. Likewise, the vulnerabilities and protections for the gateway, Web server, and backend server are similar to those for the administrative server. Therefore, we will not specifically cover the protections for the gateway, Web server, and backend server. In performing an analysis of an actual system, you would want to call them out specifically so that you can perform the define phase, where the trade-offs between security, functionality, and managerial properties are decided.


Prioritizing

Unless you have unlimited resources to apply to the system, you are probably wondering how to prioritize the protections identified. We have done a lot of work so far, and you have a lot of data that must be examined during the next I-ADD define phase, where you make the decisions about which to implement and which to forego. To assist with prioritizing the protections, we recommend creating a vulnerability/protection covering matrix. For those not familiar with covering matrices, what we are referring to is basically a chart. For a large or complicated system, this could be a huge chart.

Along the vertical side (rows), you list the vulnerabilities, and along the horizontal side (columns), you list the protections. There are two ways to fill in the chart, depending on what you are trying to accomplish. You can simply put an X or some other symbol to indicate that the protection works against a given vulnerability. An alternative is to provide a numerical value, on a scale that makes sense for your particular system, indicating how well the protection works against the given vulnerability. We prefer the latter in most cases because it enables you to identify or prioritize the protections based on utility and not simply on the minimum protections needed to cover all the vulnerabilities.

We want to stress that filling the matrix with numerical values is not a trivial task. It requires security expertise to assess the utility of a protection mechanism accurately against a particular vulnerability. Performing this activity without this expertise could provide a false or inaccurate assessment, which would cause your system to be under-protected and vulnerable. Although this may be acceptable, the risk being assumed should be a conscious effort. This can be accomplished only by having complete and accurate information on which to base these decisions.

As an example, let us create a portion of the vulnerability/protection covering matrix for our sample generic system. We will look at the vulnerabilities of the wireless device itself to loss and theft. We will examine only these two aspects so that the chart doesn't get too big. This should be sufficient to demonstrate how the matrix is created.

You generate a matrix with the vulnerabilities of the physical device along the rows and the protections along the top. You then fill in the matrix with values indicating how well the protection works against the vulnerability. We will use a scale of 1–5, in which 5 indicates the most protection and 1 the least. Again, how you determine the scale and the differentiators between a 4 and 5, for example, is dependent on the system, your level of expertise, and how you intend to use the information. The scale and differentiators should be identified and agreed on ahead of time if this is going to be a team effort. Because this is a nonspecific system, you use the numbers as a relative weighting against the other protections. Table 11.1 depicts what your vulnerability/ protection covering matrix would look like.

You can now see how certain protections provide utility against more than one vulnerability. Also note that not all protections have utility against a given vulnerability, particularly as you expand the matrix to encompass the entire system. One additional aspect (which isn't captured here but could be) is to indicate that a listed protection may actually assist a vulnerability to be exploited. For example, a smaller device may make it easier to steal, so perhaps there should be a -2 in that column.

Table 11.1. A Vulnerability/Protection Covering Matrix

Protection Vulnerability

Smaller Device

Carrying Case or Holster

Wearable Interface

Proximity Sensor Token

Lower Device Cost

External Authentication

Biometric Authorization

Loss

1

2

4

4

5

Theft

1

3

2

5

4

5

Looking only at the chart, we see that making the device inexpensive clearly is the best single choice to address both these issues. Logically, this makes sense but may not be an acceptable trade-off when weighed against the managerial factors. However, that analysis is done during the next phase. This table should strictly capture the utility of the protections without regard to implementation or other factors. During the next phase, these numbers can be modified in another matrix, which captures the utility considering these other factors. Then an overall matrix containing a weighted number combining all the previous charts can be made. Again, there is flexibility here to use this tool as it best fits the needs of the analysis being performed.

One final point we want to emphasize is that although picking a single protection for each vulnerability may be tempting, it is not the best approach from a security perspective. The use of a single protection mechanism may provide a simple obstacle for the would-be attacker to overcome and, therefore, would be worth the attacker's effort to exploit. The use of multiple protections tends to increase the overall security tremendously because compromising a single protection does not necessarily leave the system vulnerable.

Additionally, the use of one protection can enhance or be enhanced by another protection. For example, implementing a wearable device provides some theft protection, as well as loss, but allows biometric authentication to be performed more readily, which has great utility against theft. Redundancy of protections against a vulnerability should be attempted when feasible, particularly if the individual protections do not have very high utility.


Building Trust—Application Security

But that can't happen to us because it's always been a matter of trust.

—Billy Joel, "A Matter of Trust"

In closing this chapter, we get around to the core component over which developers have control: application security. The number of protections you place in an application is dependent on the level of trust you place in the rest of the system components' having done the right thing. Before going any further, let us share a colorful phrase often used by one of our co-workers that summarizes one way to view this: "If you didn't build it, it's crap!"

Granted, this may be extreme in most situations. It does, however, set the stage for the key to application security, which, when it comes down to it, is the entire purpose of this chapter. This key is, application developers should do what they can to ensure the integrity, security, and utility of the data or resources their applications provide, utilize, or transport. Further, developers should not rely on others for their security and should do what they can in this regard.

To put it more generically, those responsible for each component of a system should do what is in their power to provide protections for resources or potential targets for malicious attackers. If it is necessary for you to rely on another component or resource to provide this protection for you, do not assume that this has been done. Verify that what you expect to be present and functional actually is. Anticipate failures or compromises in these protections, and have redundant or supporting mechanisms in place to protect critical information or components. If the protections required are outside the scope of your portion of a system, you should monitor or log activity and issue a warning when something potentially unscrupulous is detected.

In closing, we leave you with another quote, which verges on being rather "spy versus spy" in nature. You have followed the I-ADD process and have done all that is within your power to protect the resources of concern. There may still be areas where the system is vulnerable, either because of the security/functionality trade-offs (more on this in Chapter 12 , "Define and Design") or because you intentionally presented or left a vulnerability unmitigated. However, this seeming vulnerability is heavily monitored as an early warning system for potential malicious activity. The point being, sometimes knowing when you have been compromised can be as important as protection against the compromise. If you can't protect, detect.


Chapter 12. Define and Design

In theory, there is no difference between theory and practice. But, in practice, there is.

—Jan L.A. van de Snepscheut

Now, if you have just finished reading Chapter 11, "Analyze Mitigations and Protections," you might be feeling overwhelmed. The ideal situation for securing components of a wireless system was presented to you. If we had been in a room with a whiteboard, we would have attempted to capture the information of a best-case scenario for protection. You should feel assured that you have investigated the intricacies of each component of the system. You have investigated the networks, technologies, development languages, and devices. We have also outlined the steps necessary for you to analyze the risks in a given system and integrate those risks with the knowledge of a system. At this point, having completed the I-ADD identify and analyze phases, you should feel confident that you know the system you are investigating.

In your own wireless system, whether at home or in an office, perhaps some years after this book is printed, you will need to do your own investigating into the details of each component of your system. Perhaps the mobile device you use to connect to a wireless LAN in your home will be nothing like those described in Chapter 4, "Devices." You should consult whitepapers, technical documents, SDKs, and the like, to determine the specific security issues associated with that device. Perhaps the WAP debate will be over. WAP may be a distant memory of the early part of this decade, and Bluetooth may have never gained enough marketshare to be considered a contender for a wireless cable replacement technology. Perhaps the IEEE will be revising its 802.11t standard, having gone through ten ramifications since 802.11b. Whether any or all of this is true, you have learned the process necessary to secure a wireless, or any information processing, system.

To recap, you must know the system inside and out to protect it. You must understand its capabilities and its hindrances. You must have a firm grasp of security concepts to know what you are working towards. With this knowledge, you sit down, as demonstrated in Chapter 11, and map out the perfect security solution for your system. Then you will take a step back and realize one fatal flaw—you do not have a budget large enough to afford the solutions you have proffered. Also, you will have very angry users if you develop applications and technologies so airtight that they can protect life-threatening information. Why? Because the price for this protection is severely restricted functionality. Unless you work for an organization that protects national security, the "best" (and, mind you, we use that term loosely) security solution in theory is not necessarily the best one in practice. Certain trade-offs need to be made. This trade-off process is much more difficult than developing security solutions in a budget-free and constraint-free environment. That environment is not the real world, though.

The challenge during these last two phases (define and design) is choosing from the available options to create a tailored, specific, feasible solution that fits within budget and time constraints and offers the right amounts of security to the appropriate portions of your system. Fortunately, you have already gathered all the tools necessary for completing this seemingly insurmountable task. The identify and analyze phases are both time- and resource-intensive. The define and design phases are straightforward. In smaller systems, the two processes can be completed simultaneously.

To make good decisions with respect to security/functionality trade-offs, you need priorities. These have already been decided. In the identify phase you determine the data to be protected and the roles of persons who have influence over targets (we compiled an extensive and exhaustive list). In Chapter 11 , you use these items in the analyze phase to develop general mitigations and protections.

To give meaning to these mitigations and to prioritize during the define and design phases, you will revisit the case studies from the first chapter. Only when examined in the context of an actual system is it possible to identify the appropriate strategy for developing a security solution. For the sake of demonstrating this security/ functionality trade-off process, we will introduce specifics into each case study in order to develop an appropriate solution. In Chapter 11 we suggest the use of vulnerability/protection matrices. These should be used in security planning. In the interest of space, we are not going to present comprehensive, exhaustive charts here (the process of filling in those charts is outlined in the Chapter 11 ). Instead, we will provide an analysis based on the results of those charts that are important in understanding the ramifications of each wireless system in the case studies.

The design phase is not an assessment phase like the previous three phases (identify, analyze, and define). It is more a philosophy or methodology that allows the incorporation of security measures into a system efficiently and cost-effectively. If the time is taken to perform the process on a system during the early stages, the security measures are much easier to design in to the system, rather than try to patch them into a system already under development or developed. Knowing the risks you are assuming is as important as knowing what protections are in place.

The first step in the I-ADD define phase of making security functionality trade-offs is to eliminate target categories that are beyond control. In all four of the case studies, the transceiver is beyond control. Unless you are the device manufacturer, you cannot implement the mitigations identified for transceivers. Therefore, to this end, you have to evaluate the risks you incur when you cannot mitigate. In the case studies, the risks may be of relatively low importance. The transceiver is left vulnerable to malicious parties causing the following:

· Modification and manipulation

· Denial of service at crucial times

· Access to unauthorized users (who may not pay, may use the service to spam, and so on)

· Transmission of inaccurate information

These risks are relevant but unavoidable at this time. Because they are beyond your control, mechanisms to detect each should be determined during the design phase. An appropriate plan must be devised that would go into effect should any of the problems listed come to pass. The risks involved with vulnerabilities at the gateway fall in the same category.

The rest of the targets discussed in the mitigations and protections bear some relevance in each case study. Now your job is to determine which are important enough to mitigate and at what cost.


The Case Studies Revisited

Without further ado, let us look at the first case study, the hospital (refer to Chapter 1, "Wireless Technologies").

The Hospital

In the hospital scenario, much is at stake. You are concerned with protecting a lot of information (now required by federal law—see Chapter 8, "Privacy," for information on privacy and legislation), some of which is critical to Reggie's staying alive. In this case study, you are concerned with avoiding, first and foremost, loss of life, then financial loss and loss of privacy, and last, scheduling conflicts. Several pieces of data that need to be protected in transit, during storage on servers, and in presentation and storage on the device could be critical to Reggie's life and health:

· Medical records and history

· Diagnoses

· Recommendation for surgery

· Prescription information

Also, certain data that needs to be protected in transit, during storage on servers, and in presentation and storage on Reggie's device could, if compromised, cause him to incur financial loss:

· Credit card information

· Voice approval for credit card authorization

· Insurance information

Other pieces of data that need to be protected in transit, during storage on servers, and in presentation and storage on Reggie's device could, if compromised, result in his loss of privacy:

· Medical records and history (including all related events of the day)

· Insurance information

· Credit card information

Finally, certain data that should be protected in transit, during storage on servers, and in presentation and storage on his device could, if compromised, result in an inconvenience (namely, a scheduling or timing conflict):

· Surgery scheduling

· Appointment scheduling for follow-up

These groups of data fit in different places in the mitigation and protection schema. Six of the identified protection categories are most significant in this case study. In making security/functionality trade-offs, the most relevant should be considered first. For the hospital, the following should be considered:

· Protecting the wireless device

· Protecting personal data on the PDA

· Protecting corporate or third-party information

· Protecting corporate proprietary data and resources

· Protecting the network server

The next step is to integrate the data priorities with the protection categories. We will go through the identified protection categories in the bulleted list and apply our priorities in choosing mitigations. All mitigations are chosen from the information in Chapter 11.

Protecting the Wireless Device

Although device manufacturers play a certain role in this protection category, it is up to Reggie and Anne to take necessary precautions. Reggie risks losing his own personal data, which, although potentially dangerous, affects only him. Anne, on the other hand, puts many other people at risk by losing her device, so she must go to greater lengths to protect hers. Reggie could simply employ a holster so that his device is wearable, but Anne could be required by the hospital to use an external authentication mechanism to access the device to ensure that, in the event of loss, no one else can access the information available to the device. (See the protection/vulnerability matrix at the end of Chapter 11 for how we arrived at this conclusion.)

Protecting Personal Data on the PDA

In this protection category and case study, we will assume that the application on Anne's PDA that allows her to view medical records and the like is a proprietary application. Taking a look at the mitigations suggested in this category, we can be astute architects of this system and have the foresight to implement a certification program. Enforced by the OS on all PDAs used by doctors in this hospital, this would allow only digitally signed code from authorized certifiers to be loaded on the device. The software could then be validated to be secure, reliable, and functioning as intended. The authenticity and integrity of the code could be maintained, and we could mitigate the risk of a malicious application developer's compromising Reggie's surgery by inserting dangerous code into Anne's PDA.

In this hospital's budget, security is important but limited. The hospital believes that this code certification solution is enough to mitigate the application risk. It does not want to invest in a trusted OS for each device, nor the time and money involved in implementing a hardware resident integrity check of the device and OS. The hospital will, however, provide funding to purchase an additional encryption program for the PDAs so that malicious application support personnel cannot compromise stored data. There is a drawback to this added encryption program, however. Anne's battery lasts only for about 24 hours. Sometimes Anne is required to work 36-hour shifts, and on these shifts she must operate without her Compaq iPAQ PDA for 2 hours while the battery is recharging. She is not pleased with this solution because she needs constant access to her information, so she is pressing the hospital wireless security team for a better solution.

Reggie's funds are far less than those of the hospital. He spends most of his money in co-pays these days and cannot afford to purchase an extended encryption program for his PDA. He, instead, relies on himself to keep the device out of the wrong hands.

Protecting Corporate or Third-Party Information

In the hospital, device and application support personnel are one and the same. The encryption application on the device has no back doors and offers reasonable protection against these individuals' possible attempts to commandeer a device or its data. You do not have control over the WSP personnel in this case. The risks left open there are somewhat mitigated by the extra encryption. The mitigations used in the preceding section to protect information apply here as well.

Protecting Corporate Proprietary Data and Resources and the Network Server

Data on the administrative and network servers that needs to be protected is subject to malicious WSP personnel, application developers, application support personnel, and users. You do not have control over the WSP personnel, and risks there are significant. Any persons with access to the hospital's servers can access and manipulate patient data, records, X rays, scheduling, and prescriptions. This is extremely dangerous.

To protect the server, we will choose mitigations from the lists developed (in Chapter 11). Sensitive data will be stored in an encrypted form, authentication will be required before allowing access to sensitive data, access and activity on the system will be logged, and use of a physical token will be required as part of the authentication process. These will mitigate risks posed by all noted potentially malicious parties. The servers are mitigated outside the realm of a wireless system. They are secured with common wired-technology techniques. In addition to these mitigations, it is important to secure the wireless link administration interfaces that connect to the servers with the same protection afforded Internet or other untrusted traffic.

Considerations

Several mitigation techniques were selected, bearing in mind that some data is to be protected at greater cost than other data. The servers and devices in this case study contain highly sensitive data that requires integrity and privacy to a paranoid degree. The hospital does not go to the nth degree in securing its systems. Not every offered mitigation technique was employed, but an appropriate set was determined. Anne still wants to find a better solution for her necessity to recharge her device in the middle of her shift. This can be done in a variety of ways, whether it be engineering an encryption solution in a development language such as J2ME, which is less battery-intensive, employing an Elliptical Curve Cryptography encryption algorithm that is less battery-intensive, purchasing longer-lasting batteries for her device, or perhaps even switching to a less resource-intensive device, such as a Handspring Visor Edge with a Palm OS that has an expansion capability for memory expansion, as well as encryption.

Reggie, by the way, hangs on tightly to his device and recovers easily from his surgery, updating Anne periodically with status reports that allow him to minimize his trips to the hospital for follow-up visits. Because the hospital appropriately protected his credit card information (and was fortunate not to have malicious insiders compromise the system), he has not seen any unauthorized transactions on his statements and was billed correctly for his co-pay.

Using Wireless Devices in a Medical Environment

Another aspect to our hospital case study is the use of wireless devices in a hospital. We do not investigate the networks and communication in great detail, but implementing a wireless solution in a medical environment is tricky. Wireless devices can cause conflicts, malfunctions, or other problems with heart monitors and other critical medical technologies. Wireless communication can be implemented in a hospital only with strict adherence to restrictions and very close communication among medical technologists and wireless technologists to develop explicit and exhaustive plans for use or prohibition of different types of wireless technology throughout the hospital system.

The Office Complex

AdEx and NitroSoft are embarking on a presentation. In this office complex case study, you do not have any data that is critical to someone's life or health. No data can cause direct financial loss. You do have time-critical messages and proprietary sensitive data. After examining a hospital situation, this seems almost pedestrian. It is business-critical, however, and businesses invest good money in wireless solutions that must work.

To close this deal, Kathleen needed to deliver the best presentation possible. Without instant communication from her team members, she would not have been able to schedule the lunch meeting and subsequent presentation properly. Losing or damaging the acquisition information Louis sent her to incorporate into the presentation would have been potentially damaging to their relationship and a potential dealkiller. If Louis saw a similar pitch from three other advertising firms and Kathleen was able to adapt the most quickly and make efficient use of Louis's time, he will choose to do business with AdEx every time. The data that needs to be protected here are the presentation slides, the information sent by Louis, and the contents (and transmission expediency) of the e-mail exchanges.

The data in this case study fits in different places in the mitigation and protection schema. Two of the identified protection categories are most significant in this case study. In making security/functionality trade-offs, we will consider the most relevant first. For this second case study, the following should be considered:

· Protecting the wireless device

· Protecting corporate or third-party information

This may seem troubling—only two of the protection categories? For this isolated example, that's exactly right. The users are not accessing sensitive information on corporate servers, and they should not be storing personal information on devices used for work. The devices are used to send and receive information in this case.

Protecting the Wireless Device

In this case study, no extraordinary means need be taken to secure the physical devices. Kathleen, Louis, and their respective co-workers are conscientious and enable passwords to secure their devices.

Protecting Corporate or Third-Party Information

The presentation and e-mail messages exchanged between the players in this case study should be protected in transmission and on the device. Only designated recipients should receive e-mails, and the time stamps on those e-mails are critical. Device support personnel, WSP personnel, application developers, and application support personnel are beyond your control because this is not a proprietary application or device.

The wireless solutions used by Kathleen and the AdEx staff are Pocket PCs. They make use of the slimmed-down office products available for their devices, and their company has not engineered any solutions on top of the devices. The Pocket PCs are used out of the box and have no encryption capabilities. AdEx is operating on a limited budget, and even the few mobile devices it has consented to procure are stretching its funds.

The appropriate mitigation for this situation is institution of a checklist and an oversight procedure. This technique is typically applied for application support personnel to ensure that any security bypass settings or diagnostic modes have been properly reset to operation settings. In this case, however, it is used to ensure that the settings on each device are compliant with the company security standards. What Kathleen and her team can do to protect others from viewing their presentation is to protect the individual document with a password.

The data is at risk during transmission because no encryption is employed. The group could switch to a BlackBerry solution so that encryption is native to the device. However, they would not be able to view presentations or other office documents on their PDAs. The trade-off they are willing to make is that, although their transmitted data is vulnerable to capture by anyone sniffing the wireless network, they are afforded some protection by password-protecting the document. They accept this risk in return for being able to integrate office documents quickly and easily between their desktops and Pocket PCs.

A key point here is that the users and not just the system engineers must understand and accept these limitations. When trade-offs are made that affect how a system operates or there are areas where users may make assumptions about how the system operates, users must be informed about the risks they are assuming and the appropriate actions they should take to mitigate these risks.

The NitroSoft group does use BlackBerry devices, so they cannot view attachments but are able to forward them to the AdEx folks. Their communication is secured only between the redirector on each one's desktop and the BlackBerry device. When they forward the message, the message and its attachment can be viewed in the clear.

Considerations

In an office scenario, financial motives, incentives, and risks are often a driving force in decision-making. When other features, such as reliability, speed, profit, or commercial appeal, are at stake, security is often relegated to the lowest priority. Sometimes this is acceptable, and sometimes it isn't. Very few development projects finish ahead of schedule and under budget, so finding ways to recover time and money is important. For NitroSoft, implementing all the security solutions we suggested may or may not be financially sensible. Performing a return on investment (ROI) analysis might be a good idea here. Because you are not concerned with people's lives, you do not have the same urgency as a hospital scenario. You do want to ensure profitability and sound business practices, though, so you do not want to let security fall by the wayside. Examining the financial benefits of building security into your environment gives you information essential to making good business decisions.

The University Campus

The university case study opens the door to interesting questions of data security. The data to be protected may not be apparent at first glance, but the biggest risk is cheating. Steve, Brian, and Jessie's laptops are subject to college students' attempts to gather information about assignments, projects, and tests while online. During Brian and Jessie's NetMeetings, they are targets for streams of attacks. Additionally, if students could access Steve's grading spreadsheet, they could give themselves better grades and not worry about cheating on subsequent tests. All the data to be protected here is of an academic and integrity-oriented nature. Furthermore, Steve, Brian, and Jessie's personal data needs to be protected so that, unbothered, they can continue with their own research.

The devices are the easy part of this case study. They are all laptops with wireless NICs that operate via 802.11b. The data on these laptops can be encrypted, but the transmission cannot. If you recall from Chapter 6, "Cryptography," the WEP algorithm that encrypts wireless traffic is easily broken. Unfortunately, as of yet, not much can be done outside the university's implementing a VPN solution.

The data in this case study fits in different places in the mitigation and protection schema. Two of the identified protection categories are most significant in this third case study. In making security/functionality trade-offs, you first consider the most relevant. For the university case study, the following should be considered:

· Protecting corporate or third-party information

· Protecting user online activities, usage patterns, location, and movement

· Protecting corporate proprietary data and resources

Protecting Corporate or Third-Party Information

In this case, the corporate information and third-party information are separate. The corporate information includes files such as assignments and future tests; the third-party information includes student files stored on Steve, Brian, or Jessie's laptops for grading and evaluation purposes. In this case study, as in the previous two, you are not afforded access to the WSP personnel. Also beyond your control are the application developers and support personnel—all software used in this case study is commercial and not tailored to the university setting.

The mitigation techniques used are unique here (that is, thinking outside the box) because the devices have far more processing power, memory, and space than PDAs. These laptops can be equipped with encryption software that the TAs can use to encrypt, for free, the data stored on their laptops. By simply encrypting the data, compromises by intercepting wireless traffic are negated. Students in the class could capture files but would not be able to decrypt them without knowledge of the owner's password and possession of the owner's private key. Alternatively, duplicate copies could be stored on the network or elsewhere so that comparisons could be made, or some other logging activities could be implemented so that unwanted activity could be detected.

Protecting User Online Activities, Usage Patterns, Location, and Movement

Students who know the TAs' whereabouts and habits can make them easier targets for attempted attacks. The mitigation techniques that could be employed (as noted in the explanation in Chapter 11) would fall victim to the situation in which a security solution gets tossed by the wayside because functionality will be lost. The TAs would, assumedly, trust their students to a certain degree and demand functionality instead of cumbersome processes necessary to obfuscate their data transmission and location information. This is a risk they assume that could result in students' cheating or altering grades.

Considerations

This case study uses solutions that are not present in the list of protections for their given vulnerabilities. We intentionally placed this here to drive home one of the points of this book: Everything has to be tailored. Sometimes, when following the process prescribed here, you will have to repeat steps, complete them out of order, or disregard previous research in favor of a new idea. As long as the process is documented and proper justification is seen for implementing a new solution, its inclusion warrants investigation.

Solutions introduced at this stage of the game are acceptable, but an auxiliary process should be undertaken if this is the case. When a solution is introduced at a late stage, the security/functionality trade-off process should be put on hold for a brief moment. During this hiatus, the new solution should be put to the same rigorous tests and justification process as the previously developed solutions. The new solution must meet the same strict standards set forth and must accomplish a viable goal.

If, at this stage, you are finding yourself inventing more new solutions than using already developed ones, something went wrong before the security/functionality trade-off piece. Perhaps, when investigating devices or technologies during the research phases, something was missed—perhaps during the identification of the roles and targets or later at the mitigation development phase. Extra time built in to a planning schedule is a nice buffer for this kind of obstacle. Nowhere in our instructions to you about devising good, solid security solutions do we say that steps cannot be repeated or revisited. To the contrary, we state that this is an iterative process, so steps can be repeated at any time necessary, while keeping in mind final goals and objectives.

The Home

The last case study in our set is one that differs for every family's implementation. In this case, Doug, the father, uses the wireless home network for business use. He needs to protect his information both in transit and in storage so that he can maintain client confidentiality. Emily uses the Internet via her wireless laptop to conduct research for a law firm. The information she views is considered sensitive. Anyone tracking her Web surfing habits or pages accessed could learn information about the cases she researches, which could be used against the firm's clients. She needs to protect her activity, as well as her data and the transmission of that data to the firm's corporate network. The children's systems introduce some extra vulnerability to the system, but this does not supersede vulnerabilities already present by the parents' use of the wireless system.

Protection of the physical device is not important in this scenario. The devices are assumed to be safe because they are not left unattended outside the home. Protecting network and administrative servers is also not critical to this case study.

· Protecting corporate or third-party information

· Protecting user online activities, usage patterns, location, and movement

· Protecting access to network and online services

Protecting Corporate or Third-Party Information

To protect business information on Doug's laptop and legal case–related information on Emily's, the two encrypt the data on their laptops. Furthermore, they offload any sensitive data before getting the systems serviced.

Protecting User Online Activities, Usage Patterns, Location, and Movement

Emily's law office is concerned enough with protecting her activity online that it is willing to negotiate with a local ISP to provide a VPN. The office realizes that several of its staff will benefit, so this is worth investing in. Emily will also encrypt her traffic by using WEP encryption, recognizing that this offers only a thin layer of protection. The combination of these two provides adequate security for her purposes.

Protecting Access to Network and Online Services

A lesser concern in this case study, but a concern nonetheless, is protecting access to the family's wireless network. The access point the family is using can be accessed from as far as 150 feet away. Their neighbors could access the wireless network in Doug and Emily's house from their own back porch. Also, someone driving by could access their network. They configure the access point to accept traffic only from the MAC addresses of the cards in each of the authorized laptops and desktops. In a corporate environment this protection would not be sufficient because it can be circumvented. Doug and Emily are sure that their neighbors will not bother. They cannot be sure that they are protected from someone driving by but are not concerned about the risk.

In this case study, you do not have control of device support personal, ISP personnel, or application developers. The family does employ passwords (which they change once a month) to access online and network services. This provides an adequate level of authentication for their situation.

Considerations

Of all four case studies, this could arguably require the least stringent security. In a typical family network, however, privacy should be considered for more reasons than protecting your private data. As of yet, sales and marketing have not been exploiting home networks to target potential customers. That is not to say that this is not around the corner. By protecting your family's information and Internet habits, you can reduce future privacy risks. The methods employed in a home network should be commensurate with your own needs. Unfortunately, this means relying on potentially amateur advice from a local technical support company. To determine the right amount of security for you, if you are a home user, learning about risks and evaluating the differences between personal and corporate solutions is the best way to go.

Case Studies Conclusion

These case studies provide real-world examples of putting security assessment and planning techniques into action. The solutions in each one were determined after the comprehensive process outlined in the preceding chapters of this book. One factor not discussed here (mostly because it instills fear into the heart of every security architect) is the human factor.

Different groups of people will inevitably arrive at different conclusions about appropriate security for identical systems. By following this process, however, the delta between two groups should be minimal. By identifying fundamental information, each group can lay out the whole system and analyze it piecemeal before making decisions. By establishing justifications for security recommendations, justifications and research can be compared to analyze discrepancies, thereby compiling the results obtained by the two groups and merging them into one security solution agreeable to all.


Just the Beginning

Although this is the functional end of our teaching you how to design and implement a comprehensive security solution, it should be the beginning of your security process. After reading this book, you have the tools necessary to begin investigating security solutions of your own. This book cannot possibly provide the right answers for every security need. You have learned that security solutions cannot come out of a box in a neat little package. They need to be specifically tailored to each individual situation and should be bolstered by copious amounts of in-depth research. To effectively protect something that needs protection, you must first understand the technologies, devices, networks, and languages, as well as the risks, business needs, and users. A good security solution should take a long time to construct. It should be reviewed, and reviewed again. The first step in designing a robust solution is to know the system you are working with. Only then can you protect it with the force it deserves.

Wireless security is not fundamentally different from any other type of security. The intricacies vary, yes, but the process is the same. What we have shown in this book is that many issues associated with wireless systems need to be understood to implement tried and true security plans effectively. The security must be woven through a system and not tacked on as an afterthought. As the wireless industry grows and changes, it would behoove all players involved to make security a top priority. This will make users happy, increase revenue, and lead to secure systems that are leaps and bounds ahead of their wired predecessors.


Afterword: The Future of Wireless Security

This book is just the beginning. Wireless security will evolve to fit continually with the needs of advanced technology. As devices change, the requirements for protecting them will, too. As infrastructure changes, the requirements for implementing comprehensive security plans will follow suit. As the public's attitude towards wireless security and privacy changes, designers and developers will introduce new market differentiators.

Will wireless devices, as we know them today, exist ten years from now? Not a chance. If you compare the first computer you saw with the one you own now, you can appreciate what the difference will be. The process we taught you in this text, however, will make your security solutions robust and tailored in such a way as to apply to third-generation and fourth-generation devices. Maybe laptops will connect seamlessly and securely to wireless networks across the globe without user intervention. Maybe cryptographic solutions will advance to the point that they can encrypt wireless communication to the same degree as wired without introducing latency into a system. Then again, maybe none of this will happen.

What is more important than playing guessing games about the next best-seller wireless technology is to build security solutions that can be expanded if necessary. A strong security plan should have hooks built in for future modifications. If you follow the process taught in this book and build a solution in to your system from the beginning, you won't want to start from scratch every time a component of the system changes.

Our research will continue to evolve as well. Security professionals and wireless professionals alike will continue to investigate new ways to make the technology better, faster, smaller, cheaper, and more secure. Each subsequent version of WEP will be investigated. New flaws will be found, and new standards created. Research will be focused in each arena we discussed here. Everything from the virtual machines, to the browsers, networks, technologies, and devices used in wireless systems should be systematically torn apart from time to time and reinvestigated. The bulk of our research will focus on the software realm. Keeping abreast of changes in your systems and addressing them via application security are crucial because application security is the realm over which you have the most control. To protect your business assets, confidential information, consumer interests and proprietary code, you need to architect solutions that are creative yet concrete.

We expect increasing standardization in the wireless world. As this happens, architecting security solutions will become less tedious. As the industry becomes more streamlined, there will be room for security standardization and widespread acceptance. The nature of wireless security is global. Technologies across continents will likely merge and shape one another's growth. Wireless security will change to meet the global needs of anyone using a laptop with a wireless NIC, a PDA, or a cell phone. The wireless market will be redefined, and wireless security research will take a different shape. The same security principles will apply, but we will continue to have new and exciting obstacles to scale. We wish you the best of luck in your endeavors.


Bibliography

"Analysis of Provisions of the Proposed Anti-Terrorism Act of 2001: Affecting the Privacy of Communications and Personal Information." The Electronic Privacy Information Center Web site [cited 18 December 2001]. http://www.epic.org/privacy/terrorism/ata_analysis.html.

Andersson, C. GPRS and 3G Wireless Applications. New York: John Wiley and Sons, 2001.

Arbaugh, W., N. Shankar, and Y. C.J. Wan. "Your 802.11 Wireless Network Has No Clothes." The University of Maryland, William A. Arbaugh Web site, 2001. http://www.cs.umd.edu/~waa/wireless.pdf.

Arehart, C. et al. Professional WAP. Birmingham, UK: Wrox Press Ltd., 2001.

Avery, M. "Putting 802.11b to the Test." In NetworkWorldFusion, 2001 [cited 24 April 2001]. http://www.nwfusion.com/revieows/2001/0205rev.html.

Batista, E. "No Last-Minute Rush for E911." 2001 [cited 17 December 2001]. http://wired.com/news/print/0,1294,47220,00.html.

Batista, E. "A Fight to Ban Cellphone Spam." 2000 [cited 10 May 2001]. http://www.wired.com/news/print/0,1294,37376,00.html.

Batista, E. "Consumer Coupons Going Mobile." 2000 [cited 17 December 2001]. http://www.wired.com/news/print/0,1294,37577,00.html.

Batista, E. "Blackberry Turns a New Page." 2001 [cited 10 May 2001]. http://www.wired.com/news/print/0,1294,43624,00.html.

Borisov, N., I. Goldberg, and D. Wagner. "Intercepting Mobile Communications: The Insecurity of 802.11." The University of California, Berkeley, Internet Security, Applications, Authentication, and Cryptography (ISAAC) Web site, 2001. http://www.isaac.cs.berkeley.edu/isaac/mobicom.pdf.

Borland, John. "Wireless Web Privacy Hole Still Wide Open." 2000 [cited 17 December 2001]. http://news.cnet.com/news/0-1004-200-2546734.html?tag=prntfr.

Boulton, C. "allNetDevices: 802.11 Subject to Hacks." Cited 17 December 2001. http://www.allnetdevices.com/developer/news/2001/02/06/80211_subject.html.

Brown, D. "Wireless Privacy Legislation Coming." In Interactive Week, 2001 [cited 17 December 2001]. http://zdnet.com/zdnn/stories/news/0,4586,2765638,00.html.

"Cellular Telephones." Cited 17 December 2001. http://www.smdc.army.mil/SecurityGudie/v2comint/Cellular.htm.

"Cellular Telephones." Cited 17 December 2001. http://users.dhp/com/~bishop/cellular.html.

Champness, Angela. "IEEE 802.11 DSSS: The Path to High-Speed Wireless Data Networking." 2001 [cited 6 April 2001]. http://www.ydi.com/pdf/weca80211.pdf.

Charny, B. "Could E911 Have Helped in Disaster?" 2001 [cited 17 December 2001]. http://news.cnet.com/news/0-1004-200-7139433.html.

"Connected Device Configuration (CDC) and the Foundation Profile." Technical white paper, Sun Microsystems [cited 31 July 2001]. http://www.sun.com.

Crowe, D. "CALEA: How Will It End?" 2001 [cited 18 December 2001]. http://industryclick.com//magazinearticle.asp?magazinearticleid=134402.

"CTIA Proposes Wireless Privacy Steps." Cited 17 December 2001. http://www.allnetdevices.com/wireless/news/2000/11/28/ctia_proposes.html.

Cukier, K.N. "Big Brother in the Air." Cited 17 December 2001. http://www.redherring.com/mag/issue78/mag-brother/78.html.

CyberCrime staff. "Turn the Tables on Cellphone Snoops." May 1, 2001 [cited 17 December 2001]. http://www.techtv.com/cybercrime/print/0,23102,8201,00.html.

>Electronic Privacy Information Center (EPIC) et al. The Federal Communications Commission. Reply comments in the matter of Telecommunications Carriers' Use of Customer Proprietary Network Information, November 16, 2001 [cited 17 December 2001]. http://www.epic.org/privacy/cpni/CPNI_Reply_Comments.html.

Davis, Noel. "PalmOS, Half-Life Server, and Ethereal Vulnerabilities." In O'Reilly Network, 2001 [cited 6 April 2001]. http://www.oreillynet.com/pub/a/linux/2001/01/02/insecurities.html.

Dempsey, J.X. U.S. House Committee on Commerce on the Wireless Privacy Enhancement Act of 1999 and the Wireless Communications and Public Safety Enhancement Act of 1999. Subcommittee on Telecommunications, Trade, and Consumer Protection. Statement of James X. Dempsey, Senior Staff Counsel, Center for Democracy and Technology, February 3, 1999.

Dempsey, J.X., D. Mulligan, C. K. Ridder, and E. Katz. U.S. Federal Communications Commission, Washington, D.C. Comments of the Center for Democracy and Technology in the Matter of Petition of the Cellular Telecommunications Industry Association for a Rulemaking to Establish Fair Location Information Practices, 2001.

Disabatino, J. "Will 'Carnivore' Intercept Wireless Email?" 2001 [cited 17 December 2001]. http://wireless.newsfactor.com/perl/story/13207.html.

"Fact Sheet: E911 Phase II Decisions." Cited 17 December 2001. http://www.fcc.gov/Bureaus/Wireless/News_Releases/2001/nwl0127a.pdf.

"Flexible Architecture for Innovative Solutions." 2001 [cited 31 July 2001]. http://www.palmos.com/platform/architecture.html.

Flickenger, Rob. "802.11b Tips, Tricks, and Facts." In O'Reilly Network, 2001 [cited 6 April 2001]. http://www.oreillynet.com/pub/a/wireless/2001/03/02/802.11b_facts.html.

Flickenger, Rob. "Using SSH Tunneling." In O'Reilly Network, 2001 [cited 6 April 2001]. http://www.oreillynet.com/pub/a/wireless/2001/02/23/wep.html.

France, M. and D. Berman. "Big Brother Calling." In Business Week Online, 2000 [cited 17 December 2001]. http://www.businessweek.com/2000/00_39/b3700104.htm.

Fratto, M. "Tutorial: Wireless Security." In Network Computing, 2001 [cited 30 April 2001]. http://www.networkcomputing.com/1202/1202f1d1.html.

Garcia, A. "WEP Remains Vulnerable." In ZDNet News, 2001 [cited 30 April 2001]. http://www.eweek.com/article/0,3658,s%253D709%2526a%253D9207,00.asp.

Gartner, J. "Bluetooth Comes to Your Notebook." 2000 [cited 10 May 2001]. http://www.wired.com/news/print/0,1294,40190,00.html.

"Getting a Grip on Wireless: Selecting the Right Device—Part One." April 25, 2001 [cited 30 April 2001]. http://www.outr.net/download_newsletter_devices_part1.htm.

Ghosh, A. E-Commerce Security and Privacy. Boston: Kluwer Academic Publishers, 2001.

Ghosh, A. K. and T. M. Swaminatha, "Software Security and Privacy Risks in Mobile E-Commerce," Communications of the ACM, (44), no. 2 (February 2001): 51–57.

Giguere, E. Java 2 Micro Edition. New York: John Wiley and Sons, 2002.

Givens, B. "Privacy Laws of the State of California." 1997 [cited 18 December 2001]. http://www.privacyrights.org/ar/callaw.htm.

Gold, Steve. "Privacy Storm Brewing over Mobile Phone Location Tech." 2000 [cited 17 December 2001]. http://www.computeruser.com/news/00/11/13/news14.html.

Gomes, L. "Is There a Hole in Your Wireless Network?" 2001 [cited 30 April 2001]. http://www.zdnet.com.au/newstech/communications/story/0,2000024993,20218522,00.htm.

Gonsalves, A. "Certicom Readies Wireless Security Product." 2000 [cited 30 April 2001]. http://content.techweb.com/wire/story/TWB20000915S0012.

"Handheld Devices: Comparing the Major Platforms." December 2000 [cited 12 July 2001]. http://www.dell.com/us/en/biz/topics/vectors_2000-handhelds.htm.

"Hardware Comparison Matrix." 2001 [cited 31 July 2001]. http://www.palmos.com/dev/tech/hardware/compare.html.

Harvey, J.A. and C. Rosselli. "Emerging Wireless Privacy Issues and the Law." Cited 17 December 2001. http://www.gigalaw.com/articles/2001/harvey-2001-07-p2.html.

Hererra, Chris. "Technical Analysis: Comparing Windows CE with Palm OS—REBUTTAL." 1999 [cited 31 July 2001]. http://www.cewindows.net/wce/windowsce-palm.htm.

"How Bluetooth Short-Range Radio Systems Work." Cited 24 April 2001. http://www.howstuffworks.com/bluetooth.htm?printable=1.

http://www.bluetooth.org.

http://www.handspring.com.

http://www.ieee.org.

http://www.microsoft.com.

http://www.palm.com.

http://www.blackberry.net.

http://www.wapforum.org.

Hutchinson, C., J. Kleinman, and D. R. Straw, eds. ARRL Handbook for Radio Amateurs. American Radio Relay League, 1990.

Jamsa, K.A. and P. Schmauder. Wireless Application Programmer's Library. Roseville, California: Prima Tech, 2000.

"Introduction to Palm OS Programming." Cited 31 July 2001. http://www.palmos.com/dev/intro.html.

Kallender, P. "Omron Uses GPS to Catch a Car Thief." 2001 [cited 17 December 2001]. http://www.eetimes.com/story/OEG20010612S0059.

Kennedy, C. J. "The Handheld Wars: Beta Max Wars Revisited." In Wireless Business and Technology Magazine, (1), 2001. http://sys-con.com/wireless//articleprint.cfm?id=70.

Knight, W. "Hacking Threat Goes Mobile." In ZDNet UK, 2001 [cited 30 April 2001]. http://news.zdnet.co.uk/story/0,,t269-s2085837,00.html.

Kingpin, "Palm OS Password Lockout Bypass." The //www.atstake.com/research/advisories/2001/a030101-1.txt. Knight, W. "Prank Leads to Fears about Mobile Security." In ZDNet UK, 2000 [cited 30 April 2001]. http://www.zdnet.co.uk/news/2000/31/ns-17205.html.

Knight, Will. "3G: Will 3G Devices Be Secure?" In ZDNet UK, 2000 [cited 30 April 2001]. http://www.zdnet.co.uk/news/2000/33/ns-17466.html.

Lemos, Robert. "Handhelds Are the New Targets for Viruses." In ZDNet News, 2001 [cited 30 April 2001]. http://www.zdnet.co.uk/news/2001/11/ns-21689.html.

Lemos, Robert. "Wireless Networks Lure Hackers." In ZDNet News [cited 12 July 2001]. http://zdnet.com.com/2100-1105-269853.html.

Lillington, K. "Irish Know Where You've Been." 2001 [cited 17 December 2001]. http://www.wired.com/news/print/0,1294,48251,00.html.

Lindstrom, A. "Security vs. Privacy." 2001 [cited 18 December 2001]. http://industryclick.com//magazinearticle.asp?magazinearticleid=132961.

Lipschulz, D. "Security Issues Tether Wireless." 2001 [cited 11 June 2001]. http://www.redherring.com/index.asp?layout=storyandchannel=10000001anddoc_id=1370019537.

Lough, D. L., T. K. Blankenship, and K. J. Krizman. "A Short Tutorial on Wireless LANs and IEEE 802.11." 2001 [cited 6 April 2001]. http://www.computer.org/students/looking/summer97/ieee802.htm.

Luening, E. "Don't Be Fooled: DCS1000 Still a 'Carnivore' at Heart." In ZDNet News, 2001 [cited 18 December 2001]. http://www.tecsoc.org/persec/webwatch/usa.htm.

Luening, E. "Cell Phone Locator Snags Funds from Intel, Ericsson." 2001 [cited 17 December 2001]. http://news.cnet.com/news/0-1004-200-4767309.html.

McDonough, B. "Wireless: The Next Battle in Privacy." 2001 [cited 17 December 2001]. http://content.techweb.com/wire/story/TWB20010306S0018.

McGraw, G. Securing Java. New York: John Wiley and Sons, 1999.

Mettala, R. "Bluetooth Protocol Architecture Version 1.0." 1999. http://www.bluetooth.org.cn/documents/ProtArch.pdf.

Miller, B. "Mapping Salutation Architecture APIs to Bluetooth Service Discovery Layer Version 1.0." 1999. http://www.salutation.org/whitepaper/BtoothMapping.PDF.

"Mobile Device Management and Security Survey." May 14, 2001. http://www.afaria.com/public/pdfs/products/afaria/literature/white_papers/MobileSecuritySurvey.pdf.

"New Features in Palm OS 4.0 and the m50x Series." March 9, 2001 [cited 31 July 2001]. http://www.palminfocenter.com/print.asp?ID=1697.

Niskanen, P. Inside WAP: Programming Applications with WML and WMLScript. Boston: Addison-Wesley, 2001.

"Palm OS 4.0 Development Overview." 2001 [cited 31 July 2001]. http://www.palmos.com/dev/tech/docs/palmos40.

Pelofsky, J. "Privacy—U.S. Wireless Firms Choose Opt-in to Protect Privacy." 2001 [cited 17 December 2001]. http://www.washtech.com/news/regulation/10264-1.html.

Perine, K. "Talking about Wireless Privacy." In The Industry Standard, December 25, 2000 [cited 17 December 2001]. http://www.thestandard.com/article/display/0,1151,20860,00.html.

Perkins, C., ed. Ad Hoc Networking. Boston: Addison-Wesley, 2001.

Peterson, M. M. "House Panel Votes to Create New Privacy Commission." In Government Executive Magazine, 2001 [cited 17 December 2001]. http://www.govexec.com/dailyfed/0501/051001njns.htm.

Phifer, L. "Wireless Privacy: An Oxymoron?" 2001 [cited 17 December 2001]. http://www.80211-planet.com/columns/article/0,4000,1781_786641,00.html.

Pinna, Bob. "Security—The Necessary Evil." In Wireless Business and Technology Magazine, (1), 2001. http://sys-con.com/wireless//articleprint.cfm?id=67.

Radding, A. "Crossing the Wireless Security Gap." In Computer World, 2001 [cited 30 April2001]. http://www.computerworld.com/storyba/0,4125,NAV47_STO55583,00.html.

Raul, A. "O Customer, Where Art Thou?" 2001 [cited 17 December 2001]. http://www.business2.com/articles/mag/print/0,16943,9304,FF.html.

Robinson, S. "Cell Phone Flaw Opens Security Hole." In Interactive Week, 2000 [cited 17 December 2001]. http://www.zdnet.com/zdnn/stories/news/0,4586,2628754,00.html.

Russell, D. and G.T. Gangemi, Sr. Computer Security Basics. Sebastopol, California: O'Reilly and Associates, 1991.

Sanei, S. "Building Applications for BlackBerry Wireless Handhelds." 2001. http://www.blackberry.net/developers/na/c_plus/knowledge/presentations/download/motient_partner.pdf.

Santalesa, Rich. "The War over 802.11x Security." In ZDNet News, 2001 [cited 11 July 2001]. http://zdnet.com.com/2100-1107-503897.html?legacy=zdnn.

Savage, M. and A. Stirpe. "Under Surveillance." 2000 [cited 17 December 2001]. http://www.crn.com/Components/Search/Article.asp?ArticleID=22049.

Schiller, J. Mobile Communications. Boston: Addison-Wesley, 2000.

Schlichting, J. D. "The Regulatory Backdrop: Wireless E911, CPNI, and the Wireless Communications and Public Safety Act of 1999." 2000 [cited 17 December 2001]. http://www.fcc.gov/911/enhanced/regbackdrop.pdf.

Seifried, K. "802.11 Wireless Security." 2001 [cited 30 April 2001]. http://www.securityportal.com/closet/closet20010207.printerfriendly.html.

Shim, R. "Report: Bluetooth Not Making the Connection." In ZDNet News, 2001 [cited 30 April 2001]. http://www.zdnetindia.com/news/features/stories/20718.html.

Singhal, S. et al. WAP-the Wireless Application Protocol: Writing Applications for the Mobile Internet. Boston: Addison-Wesley, 2001.

Smith, R. "E911: Big Brother's Tracking System." 2000 [cited 17 December 2001]. http://www.privacyfoundation.org/commentary/print.asp?id=23andaction=0.

Somogyi, Stephan. "802.11 and Swiss Cheese." In ZDNet News, 2001 [cited 18 April 2001]. http://zdnet.com.com/2100-11-529256.html.

Sovocool, D.R. "GPS Tracking Case Raises Privacy Issues." 2000 [cited 17 December 2001]. http://thelenreid.com/articles/article/art_61.html.

Speir, M. "BlackBerry Pushes a Sweet Solution." 2000 [cited 25 July 2001]. http://www.fcw.com/.

Springboard Platform. White paper, March 2001 [cited 31 July 2001]. http://www.handspring.com.

Stenger, Richard. "Rental Driver Finds Big Brother over Shoulder." 2001 [cited 17 December2001]. http://www.cnn.com/2001/TECH/ptech/06/22/gps.airiq/.

Stubblefield, A., J. Ionnidis, and A. Rubin. "Using the Fluhrer, Mantin, and Shamir Attack to Break WEP." The Rice University, Adam Stubblefield Web site, 2001. http://www.cs.rice.edu/~astubble/wep/wep_attack.pdf.

Tanenbaum, Andrew S. Computer Networks. New Jersey: Prentice-Hall, Inc., 1981.

"Technical White Paper BlackBerry Enterprise Edition." 2001 [cited 31 July 2001]. http://www. blackberry.net.

"Technical White Paper BlackBerry Security." 2001 [cited 31 July 2001]. http://www. blackberry.net.

"The Systems Management Challenge in the Mobile and Wireless Enterprise." November 2000. http://www.afaria.com/public/pdfs/products/afaria/literature/white_papers/mobile_insight s.pdf.

Thibodeau, P. "Wireless E-Commerce Gets Mixed Reviews at FTC Workshop." 2000 [cited 17 December 2001]. http://www.nwfusion.com/news/2000/1214ftcwireless.html.

Thompson, Clive. "New Inventions Try to Simplify an Infuriating Task: How to Write E-Mail on a Mobile Phone." In GlobeTechnology.com, 2001 [cited 1 May 2001]. http://www.globetechnology.com/robmag/robmagmay_02.html.

"Top Ten Pitfalls of Wireless Application Development." March 12, 2001 [cited 30 April 2001]. http://www.outr.net/download_newsletter_toptenpitfalls.htm.

Torrieri, M. "AllNetDevices: Do Consumers Want Location Services?" In Wireless Data News, (8), no. 16, August 7, 2000 [cited 17 December 2001]. http://www.allnetdevices.com/wireless/opinions/2000/08/07/do_consumers.html.

van der Heijden, M. and M. Taylor, eds. Understanding WAP: Wireless Applications, Devices, and Services. Boston: Artech House, 2000.

Veitch, M. "BlackBerry Device Puts Email in Motion." 2001 [cited 25 July 2001]. http://news.zdnet.co.uk/story/0,s2085584,00.html.

Viega, J. and G. McGraw. Building Secure Software: How to Avoid Security Problems the Right Way. Boston: Addison-Wesley, 2002.

Viterbi, A. CDMA: Principles of Spread Spectrum Communication. Reading, Massachusetts: Addison-Wesley, 1995.

WAP Forum. "Wireless Telephony Application Specification." Technical report WAP-169-WTA, July 7, 2000. http://www.wapforum.org .

WAP Forum. "Wireless Telephony Interface Specification." Technical report WAP-170-WTAI, July 7, 2000. http://www.wapforum.org .

WAP Forum. "WAP Architecture: Wireless Application Protocol Architecture Specification." Technical report, April 30, 1998. http://www.wapforum.org.

WAP Forum. "Wireless Application Environment Specification v. 1.3." Technical report WAP-190-WAESpec, March 29, 2000. http://www.wapforum.org.

WAP Forum. "Wireless Markup Language Script Specifications v.1.2." Technical report WAP-193-WMLScript, June 2000. http://www.wapforum.org.

Weatherspoon, S. "Overview of IEEE 802.11b Security." In Intel Technology Journal, 2000 [cited 24 April 2001]. http://developer.intel.com/technology/itj/q22000/pdf/art_5.pdf.

Weil, N. "Wireless Security Flawed, Researchers Report." In PC World, 2001 [cited 30 April 2001]. http://www.pcworld.com/news/article/0,aid,40442,00.asp.

Weisman, R. "Internet Balancing Act: Law Enforcement v. Privacy." 2001 [cited 17 December 2001]. http://www.crmdaily.com/perl/printer/13088.

"Why 802.11b Should Stay Indoors." Cited April 24, 2001. http://wavewireless.com/classroom/whitepapers/802PROBLEMS.pdf.

"Wireless Communications and Public Safety Act of 1999." The U.S. Senator Conrad Burns Web site [cited 17 December 2001]. http://www.senate.gov/~burns/burns911.htm.

Wreden, N. "Wireless Overcomes Security Woes." In Information Week, 2000 [cited 30 April 2001]. http://www.informationweek.com/798/prwireless.htm.

Young, D. "Carriers and CALEA: Precarious Positioning." 2001 [cited 18 December 2001]. http://industryclick.com//magazinearticle.asp?magazinearticleid=134253.

Zhang, Y, and W. Lee. "Intrusion Detection in Wireless Ad-Hoc Networks." Proceedings of the ACM/IEEE MobiCom 2000, August 2000.


000

• | Table of Contents

Wireless Security and Privacy: Best Practices and Design Techniques
By Tara M. , Charles R. Elden
Publisher | : Addison Wesley
Pub Date | : September 13, 2002
ISBN | : 0-201-76034-7
Pages | : 304
 |  | Ripped by Caudex 2003

"The trick to sound security is to begin early, know your threats,... design for security, and subject your design to thorough objective risk analyses and testing. This book will help."—From the Foreword by Gary McGraw, CTO of Cigital, and coauthor of Building Secure Software

As wireless technology emerges into the mainstream of the networking and communications markets, the wireless development community has a unique opportunity to be proactive, rather than reactive, in its approach to security. At this early point in the wireless industry, developers can anticipate future security needs and integrate security considerations into every stage of the development process. Wireless Security and Privacy shows developers how to take advantage of this exceptional opportunity.

Written for wireless development professionals new to security, and for security professionals moving into the wireless arena, this book presents the foundation upon which to design and develop secure wireless systems. It looks in depth at the key issues faced by those who develop wireless devices and applications, describes the technology and tools that are now available, and offers a proven methodology for designing a comprehensive wireless risk management solution.

In particular, Wireless Security and Privacy documents the I-ADD process, which offers a standardized, systematic approach for identifying targets, analyzing vulnerabilities, defining strategies, and designing security into the entire development lifecycle of a wireless system.

The book also examines such important topics as:

· Fundamental wireless and security principles

· Specific wireless technologies, including 802.11b, Bluetooth, and WAP

· The security implications of the architecture of PDAs, cell phones, and wireless network cards for laptops

· The security shortcomings of wireless development languages

· Development of a risk model for a wireless system

· Cryptography essentials

· Privacy policy and legal issues

· The role of COTS products in a comprehensive security solution

· Analysis of known and theoretical attacks

· Security, financial, and functionality tradeoffs

Several case studies run throughout the book, illustrating the application of important concepts, techniques, strategies, and models.

In all, this practical guide book builds a framework for understanding the present and future of wireless security and offers the specific security strategies and methodologies that are critical for success in this fast-moving market.