Wireless Internet Security Architecture and Protocols 1st Edition James Kempf
- 1. Wireless Internet Security Architecture and Protocols 1st Edition James Kempf pdf download https://ebookgate.com/product/wireless-internet-security- architecture-and-protocols-1st-edition-james-kempf/ Get the full ebook with Bonus Features for a Better Reading Experience on ebookgate.com
- 2. Instant digital products (PDF, ePub, MOBI) available Download now and explore formats that suit you... Wireless Mobile Internet Security Second Edition Man Young Rhee(Auth.) https://ebookgate.com/product/wireless-mobile-internet-security- second-edition-man-young-rheeauth/ ebookgate.com RFID and Sensor Networks Architectures Protocols Security and Integrations Wireless Networks and Mobile Communications 1st Edition Yan Zhang https://ebookgate.com/product/rfid-and-sensor-networks-architectures- protocols-security-and-integrations-wireless-networks-and-mobile- communications-1st-edition-yan-zhang/ ebookgate.com Wireless Internet Crash Course 1st Edition Roman Kikta https://ebookgate.com/product/wireless-internet-crash-course-1st- edition-roman-kikta/ ebookgate.com Internet architecture and innovation 1st Edition Barbara Van Schewick https://ebookgate.com/product/internet-architecture-and- innovation-1st-edition-barbara-van-schewick/ ebookgate.com
- 3. Internet security and firewalls 1st Edition V. V. Preetham https://ebookgate.com/product/internet-security-and-firewalls-1st- edition-v-v-preetham/ ebookgate.com Wireless Security and Cryptography Specifications and Implementations 1st Edition Nicolas Sklavos https://ebookgate.com/product/wireless-security-and-cryptography- specifications-and-implementations-1st-edition-nicolas-sklavos/ ebookgate.com Practical UNIX and Internet Security 3rd ed Edition Schwartz https://ebookgate.com/product/practical-unix-and-internet- security-3rd-ed-edition-schwartz/ ebookgate.com Protocols and architectures for wireless sensor networks 1st Edition Holger Karl https://ebookgate.com/product/protocols-and-architectures-for- wireless-sensor-networks-1st-edition-holger-karl/ ebookgate.com Wireless Technology Protocols Standards and Techniques 1st Edition Michel Daoud Yacoub https://ebookgate.com/product/wireless-technology-protocols-standards- and-techniques-1st-edition-michel-daoud-yacoub/ ebookgate.com
- 6. This page intentionally left blank
- 7. Wireless Internet Security Architecture and Protocols Starting from a foundation in the tools of network architecture development and crypto- graphic algorithms, this text approaches wireless Internet security from the position of system architecture. The focus is on understanding the system architecture of existing Internet security protocols used widely in wireless Internet systems, and on developing architectural changes to counter new threats. The book begins with an introduction to the topics of security threats in wireless networks, security services for countering those threats, and the process of defining functional architecture for network systems. Examples of cryptographic algorithms are included, and the author goes on to discuss examples of wireless Internet security systems such as wireless network access control, local IP subnet configuration and address resolution, IP mobility, and location privacy. Each chapter describes the basic network architecture and protocols for the system under consideration, the security threats faced, a functional architecture for the security system mitigating the threats, and the important Internet protocols that implement the architecture. The text is an ideal resource for graduate students of electrical engineering and computer science, as well as for engineers and system architects in the wireless network industry. James Kempf is a Research Fellow at DoCoMo Labs USA and has been active in systems and software research since he was awarded his Ph.D. in Systems Engineering from the University of Arizona in 1983. Prior to his current position, Dr. Kempf worked at Sun Microsystems for 13 years, where he was involved in a variety of research projects, including, in 1994, a prototype of a SPARC-based tablet computer with early 802.11 supports. His research interests include wireless Internet security, new Internet architectures, and immersive user interfaces for wireless terminals.
- 9. Wireless Internet Security Architecture and Protocols JAMES KEMPF DoCoMo Labs USA
- 10. CAMBRIDGE UNIVERSITY PRESS Cambridge, New York, Melbourne, Madrid, Cape Town, Singapore, São Paulo Cambridge University Press The Edinburgh Building, Cambridge CB2 8RU, UK First published in print format ISBN-13 978-0-521-88783-0 ISBN-13 978-0-511-43726-7 © Cambridge University Press 2008 2008 Information on this title: www.cambridge.org/9780521887830 This publication is in copyright. Subject to statutory exception and to the provision of relevant collective licensing agreements, no reproduction of any part may take place without the written permission of Cambridge University Press. Cambridge University Press has no responsibility for the persistence or accuracy of urls for external or third-party internet websites referred to in this publication, and does not guarantee that any content on such websites is, or will remain, accurate or appropriate. Published in the United States of America by Cambridge University Press, New York www.cambridge.org eBook (EBL) hardback
- 11. Contents Preface page vii Acknowledgements x 1 Security basics 1 1.1 Importance of a threat analysis 2 1.2 Classes of threats 5 1.3 Classes of security services 8 1.4 Supporting security systems 10 1.5 Summary 19 2 Network system architecture basics 21 2.1 The role of architecture in network system standardization 21 2.2 The functional architecture approach 23 2.3 Example functional architecture for a simple wireless system 26 2.4 Functional architecture for network security systems 28 2.5 Example functional architecture for a wireless security system 30 2.6 Summary 34 3 Cryptographic algorithms and security primitives 35 3.1 Replay protection algorithms 36 3.2 Message digests and cryptographic hash functions 37 3.3 Shared key encryption 42 3.4 Public key algorithms 48 3.5 Key provisioning 51 3.6 Summary 55 4 Wireless IP network access control 57 4.1 Wireless network usage models 58 4.2 Threats to wireless network access 59 4.3 Functional architecture for network access control 60 4.4 Subscription-based design 72
- 12. vi Contents 4.5 Hotspot design 85 4.6 Summary 91 5 Local IP subnet configuration and address resolution security 93 5.1 Impact of the IP routing and addressing architecture on mobility 93 5.2 Review of local IP subnet configuration and address resolution protocols 96 5.3 Threats to local IP subnet configuration and address resolution 103 5.4 Functional architecture for local IP subnet configuration and address resolution security 106 5.5 Security protocols for address resolution, address autoconfiguration, and router discovery 113 5.6 Security protocols for Local Subnet Configuration Server access 125 5.7 Summary 128 6 Security for global IP mobility 130 6.1 Review of IP mobility architecture and protocols 131 6.2 Threats to Mobile IP security 135 6.3 Functional architecture for Mobile IP security 138 6.4 The IP Security (IPsec) protocol 147 6.5 Return routability 162 6.6 The limits of security architectures: the example of Mobile IP 166 6.7 Summary 167 7 Location privacy 169 7.1 Threats against privacy and location privacy 170 7.2 Security protocols for privacy in IP communication 172 7.3 Security protocols for location privacy in the wireless Internet 176 7.4 An architectural approach to location privacy 181 7.5 Summary 197 References 199 Index 202
- 13. Preface Wireless Internet Security: Architecture and Protocols approaches wireless Internet security from the direction of system architecture. A system architecture is essentially a high-level blueprint that guides the detailed design, implementation, and deployment decisions that result in a real, usable system, just like the architectural plans for a building guide its construction. Architectures serve as tools for understanding how to design and evolve a complex information technology system. Architectures are regularly developed by wireless standardization bodies to guide the development of interoperable, standard- ized protocols on interfaces between equipment provided by multiple vendors, including wireless devices used by consumers. Corporations often provide architectures as guide- lines for customers, describing how their products fit together with other equipment to provide solutions for their customers’ information technology problems. In the field of wireless security, the architectural approach has been neglected. This neglect is partially a result of the case-driven nature of network security. Most security systems have been developed in response to specific attacks that surface after the system has been deployed, rather than as a planned part of the initial system development process. Indeed, the original Internet architecture had almost no provisions for security. Internet users were assumed to be members of a co-operative community that would never attempt actions on the Internet harmful to others’ interests. This approach is changing slowly, as system designers begin to internalize the disastrous results of grafting security onto a system after a successful attack has compromised the original design. The other part of the book title, “wireless Internet,” is a somewhat broad term that covers two different types of radio links. One type, cellular links, tends to require large and deep wired access networks behind the radio link that utilize specialized protocols to manage the radio link in very detailed and radio protocol-specific ways. Cellular link protocols are quite different from the types of link layer protocols on which the Internet Protocol (IP) has traditionally run. The other type of radio link, noncellular links, does not in principle require deep radio access networks, though some noncellular protocols have introduced them as an optimization for better functioning. These kinds of links are more similar to the traditional types of wired link protocols on which IP runs. In addition, as of this writing, the current generation of cellular systems now widely deployed, 3rd generation systems, includes system interfaces which run traditional telephony protocols that are not from the Internet protocol suite or which run modifications of Internet protocols that are different from other systems. In selecting technical material to cover, I needed to make a decision about where the text should focus, and I chose
- 14. viii Preface to emphasize the use of protocols from the Internet protocol suite on noncellular radio links. These types of systems tend to have cleaner architectures and are therefore easier to understand and draw lessons from that can then be applied to more complex systems, such as cellular. Merging the Internet and cellular networks has been a more complex and challenging task than anyone thought it would be when the effort started ten years ago, but the next generation of cellular systems, the All-IP Network or AIPN currently under standardization, should eliminate most of the legacy telephony protocols and come much closer to the goal of having cellular networks fully support the Internet protocol suite. In this book, Chapter 1 discusses some fundamental issues in security for any net- work system: security threats, how to assess threats, and basic solutions and services to mitigate threats. Chapter 2 presents the functional architecture approach as a tool for developing an architecture for wireless security systems. In Chapter 3, the cryp- tographic and other security algorithms important for Internet protocol standards are reviewed. Chapters 1 through 3 present introductory material and can be skipped by those knowledgeable about the topics discussed. Chapter 4 develops an architecture for wireless network access authentication systems and describes two standardized system designs in widespread deployment – AAA server based and hotspot – and the proto- cols associated with the designs. The material in Chapter 4 illustrates how a security architecture can be instantiated into different system designs depending on the specific implementation and deployment needs. Chapter 5 discusses the security architecture and protocols involved in local IP subnet configuration systems that allow wireless hosts to securely configure an IP address and other information necessary to begin obtaining Internet routing service when they move to a new geographic area. Chapter 6 presents the security architecture and protocols for global IP mobility. Chapter 6 also shows the limits of the architectural approach. Like other information systems technology areas, a good architecture and system design do not help if the implementation introduces bugs. Security flaws can crop up at any point in the design, implementation, and deploy- ment process. Finally, in Chapter 7, a security threat very specific to wireless networks, namely compromise of location privacy, is discussed. Chapter 7 illustrates how a basic architectural change can solve a security problem in a cleaner way, at the expense of deep and possibly expensive changes in implementation and deployment. Throughout the book, I have attempted to maintain a level of detail for algorithms and protocols sufficient to provide good understanding of how the respective algorithm or protocol works, without overwhelming the reader. Certainly, any implementation effort should consult more comprehensive sources. While an introductory undergrad- uate course in network security is helpful to provide more depth, consultation of the references for additional information should be sufficient to provide background on the security algorithms. Knowledge of the basic Internet protocol suite, such as TCP and DHCP, and some familiarity with mobility protocols, such as Mobile IP, is assumed. Chapters 4 through 6 review the background on the architecture of the underlying protocols and systems prior to discussing the security architecture and protocols for wireless systems. In Chapter 7, some knowledge of IP routing is required in order to
- 15. Preface ix understand how the location privacy architectural enhancements work. Most of these topics are covered in introductory undergraduate networking courses. Each chapter after the introductory material in Chapters 1 through 3 follows a similar pattern. A particular subsystem important to the functioning of wireless networks is introduced with a review of the architecture and protocols that have been standardized to implement the subsystem. This is followed by a threat analysis and the develop- ment of a functional architecture independent of the specific standardized protocols but modeling their functionality. Interfaces are then defined between functional elements, and an overview of the standardized security protocols on those interfaces is presented. Chapter 7 is slightly different, due to the lack of any comprehensive standardized archi- tecture or protocols for location privacy. Instead, the results of a research study in how to modify the IP routing and forwarding architecture are expanded into a functional architecture for location private addressing. The goal of the book is to provide an under- standing of the underlying design principles for wireless Internet security systems to students and others seeking to know more about how current systems are designed, as well as a useful guide for designers and system architects modifying existing systems or developing new ones.
- 16. Acknowledgements This book grew out of a tutorial I presented at the Croucher Foundation Advanced Study Institute on Cryptography, December 2004, in Hong Kong, on the current state of wireless Internet security protocols. The meeting gave me an opportunity to meet with other researchers in wireless security and compare notes on the state of the art and where the field was going. I would like to thank the Croucher Foundation organizers, in particular Dr. Frances Yao of City University, Hong Kong, for the opportunity to participate in the meeting. Minoru Etoh, Eisuke Miki and Kazuo Imai, CEOs of Docomo Labs USA and my managers over the three years of intermittent effort required to write this book, were incredibly supportive in what turned out to be a very difficult and demanding task, much more difficult than I envisioned when I started writing. I would like to thank them for that support. I’d like to thank Marcelo Bagnulo and the University Carlos III of Madrid for the opportunity to give a one week seminar in June 2007 on Chapters 1 through 4. The interaction with the seminar attendees helped me refine the material in these chapters. I would also like to thank my dedicated reviewers, Erik Guttman, Cedric Westphal, and Renate Kempf, for their efforts in reviewing the book before it was submitted for publication. Any errors are of course my own but their work has helped immensely to improve presentation, understandability, and technical accuracy. Finally, I would like to thank my colleagues at the Internet Engineering Task Force and the Internet Architecture Board for many years of stimulating and informative discussion on the technical topics surrounding wireless Internet security and Internet standards in wireless and mobile networks.
- 17. 1 Security basics The Internet was originally developed with little or no security. As a government- run test bed for academic research, the user community was co-operative and nobody considered the possibility that one user or group of users would undertake operations harmful to others. The commercialization of the Internet in the early to mid 1990s resulted in the rise of the potential for adversarial interactions. These interactions are motivated by various harming concerns: the desire for profit at others’ expense without providing any offered value, the need to prove technical prowess by disruption, etc. The introduction of widespread, inexpensive wireless links into the Internet in the late 1990s led to additional opportunities for disruption. Unlike wired links, wireless links know no physical boundaries, so physical security measures that are effective for securing the endpoints where terminals plug into wired networks are ineffective for wireless links. Some initial attempts to secure wireless links had the opposite effect: providing the appearance of security while actually exposing the end user to sophisticated attacks. Subsequently, wireless security has become an important technical topic for research, development, and standardization. In response to the rise of security problems on the Internet, the technical community has developed a collection of basic technologies for addressing network security. While there are special characteristics of wireless systems that in certain cases distinguish wireless network security from general network security, wireless network security is a subtopic of general network security. Many of the same problems, design approaches, and even protocols that have been developed for wired network security can be applied to wireless network security too. This chapter discusses the background topics that are important in any discussion of network security. Specifically, in this chapter we discuss the importance of a threat analysis to good security architecture, and we review different classes of threats to network security that are important for wireless networks as well. We then review the general classes of security services that are available to help mitigate the threats. These services are each associated with specific cryptographic algorithms, which we review in Chapter 2. Finally, we discuss additional security systems that provide support for the security services. In some cases, these systems are also associated with particular algorithms discussed in Chapter 2. This chapter serves as a foundation for later application specifically to wireless networks.
- 18. 2 Security basics 1.1 Importance of a threat analysis Network security protocols are necessary on the Internet because some people are motivated to exploit or disrupt communications for financial gain or simply to prove their technical ability to do so. In addition, communications between two parties might sometimes be sensitive or involve money changing hands, in which case both parties to the communication have an interest in security. While these points might seem obvious now, they certainly were not obvious to the original designers of the Internet, since no security was incorporated into the original Internet architecture. Until the Internet was commercialized in the mid 1990s, nobody took security seriously in protocol design, with the exception of government agencies that used the Internet protocol for defense and intelligence purposes and researchers interested specifically in cryptography and other security topics. Security problems usually result from network protocols or systems that contain opportunities for unauthorized or disruptive activity in their design. An opportunity presented by a particular network protocol or system for an unauthorized party to disrupt, harm, or exploit the network communications of two legitimately communicating parties constitutes a threat against the protocol or system. A particular sequence of protocol messages and computations which successfully exploits such an opportunity is an attack. Much of network security involves identifying threats, figuring out how attacks can be mounted, and then designing fixes to protocols – or, even better, incorporating security into protocol designs before they are finalized – to thwart attacks. For network systems in general, two important steps in developing an architecture and designing the protocols are to define the problem and to list the characteristics of an acceptable solution. Without a clear and concise problem statement, it is hard to develop an architecture or design a protocol, because a network system, like any other work of engineering, is a designed object that is meant to address a specific problem. For example, the original design of the Internet architecture solved the problem of how to interconnect many different kinds of incompatible network link types, like Ethernet, ATM, etc. Once the problem is defined, a list of characteristics for an acceptable solution, often called requirements, serves to limit the solution space in order to direct design energy toward the most promising architectural solution. Without requirements, much time and energy can be wasted on adding features to the architecture that are marginally useful, or critical features can even be overlooked. Requirements also serve to highlight engineering tradeoffs – where sets of features are in conflict – and therefore where compromises must be made in the design in order to come up with something that really can be implemented and deployed. The equivalent activity for security – identifying the threats and figuring how attacks can be mounted – is called a threat analysis. 1.1.1 How to conduct a threat analysis In most cases, a threat analysis starts from an existing architecture, protocol or system design. Ideally, the threat analysis should begin when the underlying network system
- 19. 1.1 Importance of a threat analysis 3 architecture is complete but before protocol design has started. Starting prior to that is difficult, because it is hard to spot opportunities for attacks if the basic functions of the underlying system are still unknown. A threat analysis may result in changes to the underlying network system architecture, but changes in the network system architecture prior to protocol design are typically not difficult. Waiting until the protocol design is complete – which was all too often the case for older protocols that were not designed based on a good security architecture – runs the risk of having to go back and make major changes in the system architecture to enable a more secure protocol design or accepting compromises in the security imposed by existing implementations. A threat analysis is conducted by finding opportunities for disruption or compromise of communication. The following factors in a network architecture, system, or protocol contribute to generating threats: r An unprotected function in the architecture, protocol, or system design, implementa- tion or deployment that offers a dedicated and knowledgeable opponent an opportunity to attack. An example of such a weakness is a sensitive communication between two parties that is conducted in the clear, so that it can be interpreted by an eavesdropper. r A weakness in the protocol or system design, implementation, or deployment that allows inadvertent disruption of communications, where the disrupting party is actu- ally not intending to attack. Inadvertent disruption factors are typically not architec- tural in nature, since they usually arise from unanticipated bugs in a protocol or system design. An example is using a transport protocol without built-in congestion control that does unrestricted retransmission without any backoff. Such a protocol could result in severe congestion if many terminals started transmitting at once, denying service to other applications and terminals on the network. r Some basic parts of the network infrastructure can be attacked in crude and simple ways that cannot realistically be defended against. For example, an attacker could open the door of a microwave oven in an 802.11b wireless LAN cell, disabling any wireless LAN communications for some radius around the microwave oven because both 802.11b and microwave ovens use approximately the same radio frequency. Architectural solutions are not always the best way to handle a threat. For example, in the case of an 802.11 microwave oven attack, the defense is to find the microwave oven and close the door. The alternative solution of locking up all the microwave ovens in the building and requiring some kind of credentials check to use them is unrealistic and not really commensurate with the threat. This is an example of how a threat can be handled as part of the network system deployment. If the threat is not architectural in nature, then architectural solutions are obviously not the right way to address it. For example, if an application protocol uses a transport protocol without backoff for retransmission, the solution is to modify the protocol design to include proper backoff. After threats have been identified, the next step is to generate some realistic assump- tions about the nature of the attacker. If the assumptions are too lax, serious threats may be overlooked leading to attacks when the protocol or system is deployed. On the other hand, if the assumptions are too strict, the security solution may be overengineered for the actual threat. Most publicly visible mistakes in assumptions about the attacker tend
- 20. 4 Security basics to be on the lax side, since these tend to result in spectacular and widely published security failures when products are deployed and someone manages to crack the secu- rity. Assumptions on the too strict side usually delay a product’s deployment, cause cost overruns, or require users to jump through so many unnecessary security hoops that the product fails from a usability standpoint. These failures tend to look less like security failures and more like failures in engineering management and product design. A standard assumption about the attacker when conducting a threat analysis is that the attacker is able to see all traffic between legitimate parties to the protocol. While this assumption may not be true for most wired networks, it is almost always true for wireless networks. Given that, the next assumption is that the attacker can alter, forge, or replay any message they have intercepted. This allows the attacker to impersonate one of the legitimate parties or otherwise attempt to get the legitimate parties to do what they want. The attacker is also assumed to be able to reroute messages to another party, so that the attacker can team up with others to increase the computational and network power available. Finally, the attacker is assumed to have the ability to compromise cryp- tographic material used to secure traffic if the cryptographic material is sufficiently old. The safe age depends on the type and strength of the cryptographic material. Assump- tions about the identity of the attacker are also important. Many attacks are perpetrated by insiders who are known and authorized users, but who misbehave unintentionally due to compromise of their terminals by viruses or malware or perhaps intentionally due to some unknown motivation. A threat analysis cannot assume that known users will never be a threat. The amount of knowledge and resources available to the attacker typically determine whether the attacker can exploit a particular opportunity for attack, and therefore which threats should have priority for mitigation. It is never wise to assume that an attack can be deterred by keeping the attacker in ignorance about how a protocol works. Most attackers, if they are motivated to attack at all, are willing to expend the time and energy necessary to understand how to make their attack successful. Such security by obscurity is an invitation to attackers to crack the protocol or system, and thereby gain an enhanced reputation in “black hat” (bad guy) circles for their cleverness. On the other hand, increas- ing the amount of resources necessary to mount an attack – so that a successful attack becomes difficult or impossible to mount with a commonly available set of resources – is a legitimate and often-used method of deterring an attack. As we will see in the next chapter, it is actually the basis of mathematical cryptography. However, since computing power is constantly increasing and new mathematical understanding occasionally causes old cryptographic algorithms to become easily breakable, any defense based on increas- ing the amount of resources by a finite amount must consider where the boundary for a successful attack lies. Architectures and protocol designs that incorporate flexibility for strengthening cryptographic parameters and algorithms, or increasing the computa- tional power necessary to compromise a system should the boundary be reached are an important way of ensuring that designs keep current. An important consideration when performing a threat analysis is to clearly identify the value of the threatened activity or the severity of the disruption. If the value of the activity is low or the severity of the disruption is slight, measures to counteract the threat
- 21. 1.2 Classes of threats 5 should be similarly lightweight. However, care should be taken when making value judgments in this manner, since sometimes threats that are considered unlikely or minor become more important as a protocol or system is more widely deployed. Sometimes, threat mitigation measures are not intended to remove the possibility of attack entirely, but just to reduce the threat to a level that existed before the protocol or system was developed. Of course, this doesn’t help solve the underlying problem in the deployed protocols or systems, but sometimes such mitigation to existing threat levels is the only realistic choice, given implementation and deployment constraints. The process of conducting a threat analysis is unfortunately very heuristic and not very quantitative. A successful threat analysis is best conducted by donning the mindset of the attacker. The person conducting the analysis needs to ask in what clever and creative ways the particular functioning of the protocol or system can be disrupted. In the rest of the chapter, we will discuss some generic classes of threats and the security services that have evolved to counter them. Looking for these classes of threats is a good starting point when conducting a threat analysis. In Chapter 2, we discuss in more detail how a threat analysis is incorporated into the process of developing a security system architecture. 1.2 Classes of threats While every network protocol or system has particular characteristics that render it more or less susceptible to attack, a few basic classes of attacks are repeated with various per- mutations in different circumstances. The basic threat classes apply to wireless networks as well. The basic threat classes are: r replay threat r eavesdropping and spoofing r man-in-the middle (MitM) threat r denial-of-service (DoS) threat. Network security architectures, protocols, and systems have evolved to counter attacks based on these threats using various kinds of cryptographic and other security algorithms. In this section, we briefly examine each class of threat. 1.2.1 Replay threat A replay attack occurs when the attacker is able to capture traffic from one party and replay it to another, causing the targeted party to perform actions as if the traffic had been received from a legitimate sender. Replay attacks are often coupled with other attacks, such as man-in-the-middle attacks or denial-of-service attacks. In the first case, the replayed traffic is captured due to the attacker’s position as a man in the middle. In the second, the replayed traffic is used to take advantage of a flaw in the protocol design or implementation which makes the protocol vulnerable to denial of service.
- 22. 6 Security basics 1.2.2 Eavesdropping and spoofing Eavesdropping occurs when an attacker that is not a legitimate party to a conversation manages to obtain the contents of traffic between the legitimate parties. The attacker can somehow listen in on the conversation between the parties and use the information it gains. Eavesdropping is primarily a passive activity; the attacker does not engage in a packet exchange with any of the legitimate parties while eavesdropping. The attacker extracts the information of interest from the overheard packet exchange. However, in order for the attacker to set up so that it can eavesdrop, the attacker may have to perform some kind of active packet exchange with the legitimate parties to the conversation or with other parties. Spoofing means an attacker poses as a legitimate party for the purpose of tricking other legitimate parties into revealing compromising information, stealing service, or for other illegitimate purposes. One reason an attacker may spoof is to enable eavesdropping. Spoofing is typically an active attack, in which the attacker must exchange packets with the local router or a terminal in order to establish its fake identity. Once the identity is set up, the victim begins the network conversation and the attacker is free to manipulate the victim however they see fit. 1.2.3 Man-in-the-middle threat Man-in-the-middle (MitM) attacks occur when the attacker manages to position them- selves between the legitimate parties to a conversation. The attacker spoofs the opposite legitimate party so that all parties believe they are actually talking to the expected other, legitimate parties. A MitM attack allows the attacker to eavesdrop on the conversa- tion between the parties, or to actively intervene in the conversation to achieve some illegitimate end. MitM attacks are relatively uncommon in the wired Internet, since there are very few places where an attacker can insert itself between two communicating terminals and remain undetected. For wireless links, however, the situation is quite different. Unless proper security is maintained on wireless last hop links, it can be fairly easy for an attacker to insert itself, depending on the nature of the wireless link layer protocol. 1.2.4 Denial-of-service threat Denial of service (or DoS) occurs when an attacker attempts through some means to reduce the ability of a network or server to provide service to legitimate users. The nature of such attacks can run from crude to extremely sophisticated. For example, in an 802.11b or g (WiFi) wireless network, a crude DoS attack can be mounted by breaking the safety interlock on a microwave oven, then opening the door and starting up the oven. The radio noise generated by the microwave, which operates on the same frequency as the 802.11b and g wireless protocols, will overwhelm the signal from the access points. The threat from microwave ovens is fairly easy to counter, however, since the attacker and the oven must be physically located near the access point to perpetrate the
- 23. 1.2 Classes of threats 7 attack, and therefore can presumably be quickly found. Other types of DoS attacks listed in the following subsections, are harder to detect because the attacker can be remote. Bombing attacks A more serious but still crude attack is when the attacker bombards a network or server with packets designed to increase network utilization and thereby decrease throughput. Such an attack is especially effective if the attacker controls a network of machines, called zombies, throughout the Internet that have been compromised using viruses or spyware. The attacker can then instruct the machines to target a specific website or other service in order to blackmail the owner or otherwise extract some illegitimate benefit. The zombies allow the attacker to perpetrate the attack without exposing its identity, making the attacker difficult to track down. The only currently known way to handle such distributed denial-of-service attacks (DDoS attacks) is to provision the server or network with enough spare capacity so that some legitimate users can always get service, perhaps at a reduced level, or leave some capacity in reserve to be switched on for such situations. Protocol bugs and DoS attacks More sophisticated DoS attacks exploit particular weaknesses in protocol design. For example, consider a client-server protocol that takes requests from initially unknown clients, then replies to authenticate the client and set up a session. If the server maintains any outstanding state between the initial request from the unknown client and subsequent responses, the server can be subject to a storage depletion attack. The attacker continually sends the protocol initiation messages from different IP addresses without actually continuing the protocol. At some point, the server may run out of storage for the state and be unable to respond. The solution to such an attack is to design the protocol so that the server does not maintain any outstanding state from the client until the client has been authenticated. Note that this attack is not really specific to wireless networks. Redirection attacks A particular kind of DoS attack, called a redirection attack, is a consideration in the design of wireless protocols. A redirection attack occurs when the attacker sets up a session with a server for a large bandwidth data flow, such as streaming video, then redirects the attack at a victim whose network connection or device does not have the bandwidth to handle the flow volume. The victim’s network connection is overwhelmed by the traffic and legitimate service grinds to a halt. Address spoofing Finally, another attack that is not specific to wireless networks but easier to perpetrate there and therefore more common on wireless networks is address spoofing. The protocol used by IP networks on the last hop for routing has traditionally not been secure, because wired networks have in the past typically operated in situations where physical security or difficulty of access (as for example in dial-in networks) have made attacks unlikely. This protocol allows a router to map an IP address to a link layer address, so that the
- 24. 8 Security basics router can deliver the packet directly to the terminal’s interface card through the link layer. However, because the protocol is not secure, it is possible for an attacker on the same link to claim to own the IP address. The router then ends up sending packets to the attacker instead of to the legitimate owner of the address. 1.3 Classes of security services With the exception of DoS attacks, security services have been developed to counter the threats discussed in the previous section. Security services have many uses in general network security, and are an important part of wireless network security too. For example, unlike wired networks, in a wireless network, any properly configured device within the broadcast radius of a wireless access point can hear the communication between a wireless device and the wireless access point. Depending on the wireless link protocol, an eavesdropping attacker may be able to easily decode the communication and respond as the victim. If a sender on a wireless link wants to prevent eavesdropping, the messages sent and received over the link must include proof of origin to provide data origin authentication, must be encrypted to provide confidentiality protection, and must be protected against replay to avoid use of a previous message by an adversary. These are the basic security service classes. For DoS attacks, most mitigation measures focus on deployment or network management, with the exception of protocol design measures that limit opportunities for DoS. Since DoS attacks exploit some very deep and fundamental properties of the Internet architecture, they are hard to mitigate with specific system architectural measures. Most DoS attacks are also not specific to wireless networks, so they are not discussed further in the book unless they are related to specific protocol design issues. 1.3.1 Data origin authentication Data origin authentication is the process by which a receiver of a message is able to prove that the message originated from the reputed sender, and that the contents of the message were not altered en route. Data origin authentication is done for every packet in a protocol conversation if the two parties want to make sure that they are talking to each other and that no packets are modified in transit. Sometimes data origin authentication is called integrity protection, emphasizing the second aspect, proving that the message was not altered, rather than the first, proving that the message originated from the reputed sender. Data origin authentication requires cryptographic techniques in order to construct the proof of origin. The cryptographic techniques require that the two parties to the conversation possess cryptographic material that allows one party to construct a proof of authenticity and allows the other party to check it. The cryptographic material is usually in the form of a cryptographic key or keys. Later in this chapter, we discuss keys and their distribution.
- 25. 1.3 Classes of security services 9 The sender constructs the proof by taking some kind of summary of the message, usually packet by packet, and performing a cryptographic operation on the summary that only the possessor of the sender’s key could perform. The summary is a short number of bytes that uniquely identify the message, and which the receiver can calculate directly from the message too. The summary must be long enough that an attacker cannot easily construct it by guessing or otherwise cheating. The receiver verifies the cryptographic proof using a matching key. When the following two conditions hold the receiver can deduce that the message was not modified in transit and did, in fact, originate with the sender: r The summary constructed by the receiver matches the summary constructed by the sender. r The receiver is able to verify a proof that only the sender can construct. 1.3.2 Confidentiality protection When people think about network security, confidentiality protection is often the first thing that comes to mind. Confidentiality protection allows the sender of a message to know that only a designated receiver is able to read the contents of the message, and that the message is unreadable to unintended eavesdroppers. Confidentiality protection is usually achieved by encrypting the message. Encryption uses some cryptographic material and a cryptographic algorithm to convert a plain text message into a cipher text. The cipher text message is in theory not decipherable unless the receiver has matching cryptographic material and knows the cryptographic algorithm by which the message was encrypted. To an outside observer without the matching cryptographic material, the cipher text looks like randomly generated bits. The receiver uses the matching cryptographic material and cryptographic algorithm to decrypt the message into the original plain text. Many different kinds of encryption algorithms having various properties are available, and in Chapter 2 we discuss two representative samples that are in wide use and provide good protection in general. Encryption, like data origin authentication, requires both sides to have a collection of cryptographic material. The kind of encryption algorithm used in a particular wireless security system design is often determined by the kind of key distribution protocol available. The processing power available for cryptography is also an important consideration when selecting a cryptographic algorithm, since each packet requires processing. Additionally, while there are many encryption algorithms that provide good protection properties when used correctly, some algorithms have flaws or weaknesses that require consideration when including them into a design. Finally, a wireless security system should never use the same cryptographic material for encryption and data origin authentication, even if the same cryptographic algorithm is used for both. Using different cryptographic material ensures that if an attacker somehow manages to break encryption, for example, data origin authentication is still protected until the attacker has a chance to break that.
- 26. 10 Security basics 1.3.3 Replay protection Replaying previous messages captured during a legitimate transaction is another possible attack that can be perpetrated. The replayed messages can clog up the victim’s processing, thereby denying service to legitimate correspondents, or they can be intended to elicit the same response that the victim provided when the message was originally received, but this time to the attacker. In either case, replay protection is an important part of general network security protocols, and is also needed in wireless security protocols. Replay protection is usually achieved by having the sender include in each message a sequentially increasing sequence number. The receiver then validates that the sequence number corresponds to an already-received packet. If the sequence number was already received, the receiver discards the packet. In order to avoid spoofing, the sequence number must be covered by data origin authentication. Otherwise, an attacker could modify the sequence number on a legitimate packet in order to cause the replay protection mechanism at the receiver to reject the packet. Many network protocols include a sequence number so that requests and replies can be matched. Therefore, providing secure replay protection often requires little more than that the protocol include data origin authentication in addition, to protect the sequence number. 1.4 Supporting security systems To perform their function, the cryptographic algorithms providing the security services discussed above require cryptographic material. Some means is required to securely provision and manage cryptographic material. The collection of cryptographic material, credentials, and identifiers for these items shared between two sides, together with the associated cryptographic algorithms to which the provisioned material apply, is called a security association. The most important part of the provisioned cryptographic material in a security association is typically the key used for the cryptographic algorithm, so key management is the basis of security association management. The next subsection discusses key management. A prerequisite for establishing a security association is that both sides of the transac- tion can verify an authenticated identity of the other. In addition, most network operators require some method whereby the identity of a network node wishing to obtain network service is verified, and the rights for particular services are authorized. If the user is charged for service, network usage and their cost must be recorded. The algorithms, protocols, and systems that implement identity management provide an important sup- port role for the basic security services, and are the topic of this section. The subsection following the next discusses identity management. 1.4.1 Key management Security processes such as data origin authentication and encryption require that both sides of a network conversation share cryptographic material, or keys, allowing them to
- 27. 1.4 Supporting security systems 11 perform specific cryptographic algorithms in common. Arranging for both sides to have the right keys prior to the need for cryptography is key exchange or key management. Designing architectures and protocols for the secure provisioning of keys and manage- ment of keys over time is one of the most difficult and complex parts of designing good wireless network security systems. The security properties of the key management system often depend on what type of cryptographic algorithm is used. Cryptographic algorithms come in two basic types: r shared, secret, or symmetric key algorithms r public or asymmetric key algorithms We discuss shared key and public key cryptographic algorithms in more detail in Chapter 2, the rest of this section provides important background material on designing shared and public key management systems. Key management for shared keys In shared key algorithms, both sides to the conversation share the same cryptographic key. The key must be kept secret from all other parties. If the key is ever revealed, the discovering party will have the ability to perform the same cryptographic operations as the two legitimate parties. This could allow the discovering party to masquerade as one of the two legitimate parties, or to decrypt encrypted messages between the two legitimate parties. The need for keeping the key secret requires either that: r one side of the conversation (typically a key provisioning server) generates a shared key and securely sends it to the other, or r both sides of the conversation deduce the shared key independently using an algorithm without exchanging any confidential material over the network. If the key is sent from one party to the other, the provisioning protocol must be properly designed. This includes data origin authentication, replay protection, and – most impor- tantly – encryption. A terminal being provisioned must be able to verify the identity of the provisioning entity and the key must be protected from eavesdroppers while it is in transit. Transport security on the shared key can be accomplished by using either another symmetric key shared between the two sides, or an asymmetric key. If both sides deduce the key independently, the algorithmic deduction can take one of two forms: r The two sides exchange nonconfidential material over the network then deduce the shared key algorithmically without reference to any preshared secret material, using a public key-like algorithm such as Diffie–Hellman. r The two sides deduce the key algorithmically from some preshared secret material, with possibly some nonconfidential material exchanged over the network for freshness. The first method is really a subcategory of public/private key management, because the algorithms used are public key algorithms. In Chapter 2, we discuss the Diffie–Hellman key exchange algorithm in more detail.
- 28. 12 Security basics For the second method, the wireless terminal must be provisioned with the preshared secret in some out-of-band fashion (e.g. typing in some numbers, through a secure hardware chip, etc.) prior to its first network access. The secret is shared with the other party to the key generation. This could be a provisioning server in the network or even another terminal, depending on the application. When the wireless terminal contacts the other party for key generation, the other party and the wireless terminal utilize the preshared secret to generate a master key. The key generation algorithm typically requires the combination of the preshared secret with some additional nonconfidential material provided by the wireless terminal, for example, a randomly generated number, exchanged during the key generation transaction. The nonconfidential material provides key freshness. The exact details of master key generation depend on the actual protocol or standard specification. The important point is that both sides independently derive the master key using the same values, one of which is the preshared secret but others of which may be publicly exposed. The master key itself is never actually exchanged between the wireless terminal and the other party, because each side derives it independently. In some protocols, a further step is required in which the other party, usually a key provisioning server in the network, securely conveys the master key to a third party that will ultimately be conducting the cryptographic operations with the wireless terminal. In this case, the key provisioning server and the third party must share a security association specifically for protecting key distribution. The master key is then used to derive session keys for use in various cryptographic operations. The session keys are derived in the same way as the master key: both sides independently combine the master key and some publicly accessible material exchanged between them in a specified, algorithmic fashion. For example, a wireless terminal and a network authentication server may generate a session key for authenticating traffic over the wireless link, a separate session key for encrypting traffic over the link, and yet another session key for securing handover signaling between one wireless access point and another. Session keys typically have a limited lifetime and must be periodically regenerated, to reduce the amount of time they are exposed to an adversary that could compromise them. The regeneration procedure is an important part of the key management algorithm. The master key itself and the preshared secret should never be used directly for cryptographic operations on the network. If a master key or preshared secret is used and somehow an adversary compromises the key, then all derived keys are put at risk too. Key management for public keys Public or asymmetric key algorithms do not require the exchange of confidential material or the prior provisioning of both sides with a preshared secret. Instead, each participant in the cryptographic algorithm generates a pair of keys. One key, called the private key, is not disclosed to any other party. The other key, called the public key (from which this class of algorithms takes its name) is not confidential and can be sent over unencrypted connections to other parties. For most public key algorithms, the public and private keys are calculated algorithmically using random numbers generated autonomously by the owner from a good pseudorandom number generator. The random numbers are then
- 29. 1.4 Supporting security systems 13 operated upon by the key generation algorithm for a specific public key cryptographic scheme to generate the public and private keys. The random numbers ensure that the private key is mathematically difficult to guess. The key generation algorithm establishes a mathematical connection between the private key and the public key that allows the cryptographic algorithm to work. Public key algorithms are sometimes called asymmet- ric algorithms because the need for confidentiality on the keys is asymmetric. The public key can be exposed but the private key cannot, unlike shared key algorithms where the confidentiality requirement is symmetric: the shared key must be kept confidential by both sides. The two keys are used for different security services in different ways. For data origin authentication, the owner of the key pair generates a digital signature on data using the private key that allows the receiver to verify the origin and integrity of the data using the public key. For confidentiality protection, the sender of a confidential message to the owner of the key pair uses the public key to encrypt data that allows the owner of the key pair to decrypt the data using the private key thereby protecting it in transit. As mentioned above, in addition to the cryptographic algorithms for data origin authentication and confidentiality protection, public key algorithms also require a key generation algorithm to generate the public key from the private key. Principles of secure key management protocols In general, an existing key management protocol having the right characteristics for the application at hand should always be preferred to developing a new key management protocol from scratch. Security protocols usually get better over time because the bugs in them are found and fixed as more and more applications use them. So older protocols – provided they are not so poorly designed as to be in effect insecure – are usually better understood and therefore better to reuse. Of course, to reuse an existing protocol, the assumptions and constraints on the protocol must be carefully noted and not violated; otherwise, a secure protocol can easily be converted into an insecure one. If an existing protocol is not a good match for a particular system, a new protocol is required. The following principles, discussed in more detail in RFC 4962 (RFC 4962, 2007), have proven successful in mitigating threats in practice and should be kept in mind if a new protocol is developed. These principles are primarily of relevance to key management protocols that provision or derive shared keys: r Confidentiality protection, replay detection, and authentication are required for key distribution or exchange protocols over the network. Keys are confidential material, and therefore proper security protection is required. In order to prevent spoofing, both sides in the key exchange must be mutually authenticated to ensure that they fully know and trust each other. Finally, replay protection is required to avoid an attacker sending an old session key obtained by snooping a prior exchange, and thereby disrupting an ongoing session. r The cryptographic algorithm used in a security protocol should be negotiable. The security of cryptographic algorithms is not fixed, and often depends on the processing
- 30. 14 Security basics power available to an adversary. Since processing power is increasing, the crypto- graphic algorithms used in a security protocol should be negotiable. This allows par- ties in the exchange to use the most secure algorithm consistent with their hardware processing power and software implementation availability. In addition, negotiations for selecting a cryptographic algorithm must be performed between authenticated entities, and the messages must be covered by data origin authentication. This pre- vents an attacker from spoofing one side of the conversation into accepting a weak cryptographic algorithm that the attacker is able to compromise. r Keys need to be kept strong and fresh. Key freshness means that keys are generated whenever a new session is started, and periodically renewed. A key must be generated specifically for the use that is intended, and the material that goes into calculating the key must be new. In addition, there must be no dependency between keys such that disclosure of a previous key compromises keys that are generated later. Key strength, which is usually a function of the number of bits in the key, must be high enough that the probability of a guessing attack or other compromise is very low. Since the limits of key compromise are changing all the time as computation power increases, protocol developers must be aware of the state of the art in cryptanalysis with respect to key length in order to make wise choices. r A key in a shared key security association is confidential material, and therefore it should not be divulged, even intentionally, to an entity that doesn’t need to know the key. An “entity” here means either a software module on the same node for which the key was derived or another network entity entirely. An entity has access to a key if it has access to all the cryptographic material needed to derive the key. The concept of a cryptographic boundary is useful in limiting key access. A cryptographic boundary is a topological scope within which the key is known, but outside of which it is kept secret. A cryptographic boundary encompassing a secure hardware chip is more secure than a software module in the operating system kernel. Similarly, a cryptographic boundary encompassing a single node and the associated server is more secure than one consisting of the server and several other network entities like wireless access points. The smaller the cryptographic boundary, the easier it is to limit potential compromises, and to detect compromises when they occur. r Authorization checking is required, in addition to authentication. This prevents a terminal that can be authenticated from claiming a higher privilege or more services than it is entitled to. When more than one network entity is involved in the protocol, all must agree on the authorization for the requesting terminal. r Damage from key compromises should be limited. The compromise of a key is a serious problem, and, although well-designed security algorithms can prevent com- promise from passive or active eavesdroppers, compromises in other ways that do not involve an attacker just having access to network traffic are possible. For exam- ple, an attacker can get access to a key by stealing the physical hardware device and extracting the key from it. Propagation resistance has many implications, but one is that authenticating entities should never share secret material, and new keys should be derived every time a terminal moves from one authenticating entity to another.
- 31. 1.4 Supporting security systems 15 r A unique context for keys should be established consisting of the following information: – a unique name; – the way in which the key is expected to be used which includes not only the cryptographic operation (for example, data origin authentication) but also the specific application (for example, securing the last hop at the wireless link layer); – other parties that are expected to have access to the key; – the expected lifetime of the key. All parties with access to a shared key are expected to agree about the context in which the key is to be used. Each context should have a unique key, in order to reduce the risk that the compromise of one key affects more than one application. 1.4.2 Identity management Identity management and key management are intimately tied together. A prerequisite for secure key provisioning is a proof procedure whereby both sides to the transaction can verify the identity of the other side. Network operators also require the ability to verify the identity of wireless terminals requesting network access. Key provisioning often accompanies identity verification during network access, since once both sides have verified each other, any keys generated from the transaction are tied to a verified identity. The subsections below discuss identity management for public keys and authentication, authorization, and accounting for identity management during network access. Public key certificates Although there is no requirement in public key systems that a public key is kept secret, most applications of public key algorithms require a method allowing a party receiving a public key from another party to cryptographically verify the identity of the party sending the public key. If verification is lacking, it is possible for an attacker to claim the identity of a legitimate party and conduct a transaction with a victim that the victim thinks is authenticated but which in reality is the attacker spoofing the identity of another party. A common way of providing identity verification for the public key is a public key certificate. A public key certificate is a collection of structured data containing the owner’s public key, information verifiably identifying the owner of the key pair, an indication of the rights of the owner to utilize the public key for various applications, and the expiration date of the certificate. The certificate is signed by an entity, known as a certificate authority, whose identity is available, known, and trusted, by a broad variety of other nodes that might want to obtain the verified public key of the public key owner. The certificate authority in effect vouches for the identity of the public key owner. Naturally, for the public key owner to obtain the certificate authority’s signature on the owner’s certificate, the public key owner must prove their identity to the certificate authority. The process is similar to obtaining a notarized document. The owner of the document goes to the notary with some kind of proof of identity, like a birth certificate,
- 32. 16 Security basics passport, etc. The owner signs the document in front of the notary. The notary verifies the proof of identity, stamps the document, and signs it. The owner of the document then uses the document to perform a financial or legal transaction of some sort that requires third party proof of identity. For public key systems, the receiver of a public key certificate verifies the identity of the public key owner by verifying the certificate. The receiver uses the public key of the certificate authority to verify the digital signature on the certificate using a public key authentication algorithm, just as it would with any other data requiring data origin authentication. If the signature matches, the receiver knows that it can trust the information in the certificate, including the public key and identity information. The public key is then said to be certified. With a certified public key, a correspondent can trust the identity of the public key owner. This description covers the basics of public key identity management. Chapter 3 discusses a few additional aspects of public key systems that provide more deployment flexibility and security. Authentication, authorization, and accounting Owners of wireless networks often want to limit network access to users with whom they have some kind of business relationship. For example, when a business deploys an enterprise wireless LAN network, the business wants to restrict access only to employees. Similarly, access to public access wireless networks such as wireless LAN hot spots or cellular networks is typically restricted to customers who have an account with the network operator or can provide a credit card number for billing. Unlike wired networks, access to wireless networks often does not require that the user have physical access to a particular building or room, so the owners of the network cannot simply impose restrictions on who enters the facilities where the network access is provided in order to restrict who can use the network. The radio signals that carry wireless data often overflow into areas where the owner of the network does not control physical access. To maintain this kind of control, wireless devices are required to undergo a series of transactions prior to allowing the device full Internet protocol data routablity with the world beyond the immediate wireless link. These transactions consist of the following three operations: r The device is authenticated by requiring it to provide some irrefutable indication of the user’s identity and right to use the network. r The authorization of the user for network access and other services is checked. r If access to the network and other services requires the user to pay, the network sets up accounting so that usage of the services can be monitored. The architecture, protocols, and systems that provide these three functions are often lumped together as authentication, authorization, and accounting or AAA (pronounced “triple A”). Together, these three functions provide identity management for network access. Data origin authentication is often confused with the authentication of the first “A” in AAA, but the two are somewhat different. Authentication in the AAA sense is a matter of proving that a particular user has an account with the owner of the network. It is
- 33. 1.4 Supporting security systems 17 usually done only once (or potentially once per handover in a wireless network) when the device boots up into the network for the first time. Data origin authentication, on the other hand, is done for every packet exchanged between the parties. Data origin authentication and AAA authentication do touch at a couple of points. First, any good AAA protocol requires that the messages between the terminal and the AAA server during an AAA session have data origin authentication, so that the two parties to the AAA transaction can have confidence that the messages originated with the reputed sender and were not modified in transit. Otherwise, the AAA server might end up granting access to a device that it thought was authorized, but actually was an attacker, or the device might end up revealing information to a bogus AAA server. Second, after a device has been granted network access, the device and the network often undergo a key management phase, in which both sides configure keys to perform further data origin authentication over the wireless link for the device’s traffic. This ensures that only properly authenticated devices can send packets over the wireless link. Since, as mentioned above wireless links tend to be considerably less physically secure than wired links, data origin authentication is often required on the last hop wireless link to prevent unauthorized access even after network access authorization is received by the user. Many different techniques are used for authenticating and authorizing network access. For authentication, one of the most popular and widespread (but unfortunately least secure) is the username/password. Supplicants wanting network access prove that they are legitimate account holders by typing in a publicly known username and a secret password known only to them. The problem with this system is that people typically choose passwords that are easy to remember but also easy to guess, a characteristic that is said to be low entropy because the passwords are not randomly chosen. Such passwords are subject to simple automated attacks. An example is a dictionary attack where the attacker iterates through a dictionary of commonly chosen passwords until they achieve success. People also tend to reveal their passwords, often for very flimsy reasons. A safer technique is a one-time password, usually supplied by a key card. The password is only valid for a single network access authentication, and is usually generated using a keyed hash function, where the key is shared with the AAA server granting access to the network. The drawback of key cards is that they sometimes break and are easy to lose. Authorization typically follows directly from authentication; that is, if the supplicant wanting network access proves that it is a legitimate account holder, the supplicant is granted network access. Some deployments may include a service profile in the AAA server, where services to which the user has subscribed other than simple network access are recorded. The initial AAA transaction provides an opportunity to authorize the supplicant for additional services, though exactly how provision of these services is enforced may vary widely. Accounting is also set up at the time the authentication for network access is done. The accounting activates mechanisms in the access network that generate records recording how many packets the user has used if billing is done on a per packet basis or how long the user is connected if billing is done on a per minute or per hour basis. Since many ISPs today provided unlimited service for a monthly fee, accounting for simple network access may be unnecessary, although it may be important for other services.
- 34. 18 Security basics Many of the AAA protocols and systems in use today for wireless network access had their origin in dialup telephone access to the Internet. The basic problems involved in dialup telephone access of verifying a device or user, checking authorization for network access, and setting up accounting for service billing are superficially similar for wireless networks, which is what led engineers to adopt the same kinds of protocols for wireless deployments. The theory was that since the dialup AAA protocols were widely deployed, it would be much easier and cheaper to leverage off that deployment – the AAA servers and protocols – when setting up wireless networks, rather than deploying a whole new infrastructure for wireless networks. Unfortunately, this theory ignored a couple of key differences between dialup systems and wireless systems. These differences have caused no end of problems and kept engineers busy inventing modifications of AAA protocols to make them work better for wireless networks. In the end, it is debatable whether the strategy of modifying dialup AAA protocols for wireless access really resulted in any significant savings in deployment effort, but the wireless AAA protocols are becoming increasingly widespread and therefore are of importance. One difference is that in a dialup network, the last hop link between the dialup modem at the user’s premises and the IP network can, for all intents and purposes, be considered secure. Once a signal enters the wireline telephone system, it is extremely difficult for an unauthorized device or person to obtain access to the signal. This is not due to any particular combination of technological security features; but rather, is a result of two characteristics of the circuit-switched telephone network: r The protocols used in the circuit-switched telephone network are not widely known. r The network itself is designed in a way that makes it difficult to obtain access to an identifiable end-to-end data stream without accessing one of the switches through which the data stream runs. Since telephone companies tightly restrict who has access to the large switches that run the system, nobody can get access to a call unless they know how and are authorized. In effect, this is a combination of “security by obscurity” and tight control over people who work for the telephone company – not the most modern way to provide security but generally effective given the technology of circuit-switched telephony. The other major difference between dialup systems and wireless systems is that wireless users rarely stay put. Some wireless users are more nomadic. They move to a particular place, sit down, then work for a while using their wireless device without moving. When they need to move, they usually close up the device and restart their session in a new place. Laptop users are an example. Other wireless users actually use their devices while in motion. Cell phones are an example. In either case, the wireless device may be required to handover from one wireless access point to another, either after restarting or while actual data transmissions are occurring. Dialup users typically never change their point of connection after a particular session has started, and often the same point of connection is used every time a new session is started. Even for non-Internet wireless networks such as the circuit-switched cellular telephone protocols used in the second generation and third generation (2G and 3G) digital voice networks,
- 35. 1.5 Summary 19 the wireless medium is inherently insecure because the network operator cannot restrict who has access to the wireless medium, and users move about when making calls. As a result of this historical legacy, the protocols between the terminal and network adopted into wireless network architectures from dialup AAA initially had little or no security support, and no ability to easily move a fully authenticated and authorized device between one point of connection and another. This had to be modified for wireless Internet access. The rest of this book does not talk much about the third “A”, accounting. That is not because the process of recording network usage in order to collect money is not important. The reason is that basic accounting is not a security function and does not involve any security protocols. Accounting also tends to be more dependent on the particular application, and the business model for the organization owning the network. Accounting for prepaid services is done differently than for services that are billed by the hour, for example. Many private networks, such as corporate networks also do not bill for service and do not need accounting. 1.5 Summary In this chapter, we have discussed the basic nature of security for wireless Internet sys- tems. An important start to providing security for any network system is to assess the threats against the system. The threats serve as a kind of collection of requirements that the security architecture and protocols need to counter. Some basic classes of threats were described. When a threat analysis is completed and the attacks are understood, the basic security services needed to counter the threats can be determined. The three common security services are data origin authentication, confidentiality protection, and replay protection. Data origin authentication ensures that both parties in a network transaction can verify that the data originated with the expected party and that the integrity of the data was maintained in transit. Confidentiality protection prevents eavesdroppers from listen- ing in on a network transaction. Replay protection ensures that an eavesdropper cannot confuse the correspondents by sending old messages to look like new. These are the basic security services that serve as building blocks of wireless network security architectures. The basic security services require additional system support for setting up a secu- rity association containing cryptographic material, credentials, and other state shared between parties and important to operation of the basic services algorithms. Since secu- rity protocols usually require both sides of a secure conversation to possess some kind of cryptographic material, secure and effective key management is an important component of wireless network security. Key provisioning requires identity management to ensure that a provisioned key is tied to a verified identity. Permission to enter a network also requires identity verification, to ensure that the wireless terminal and its user are allowed to use the network. Finally, DoS attacks are a separate kind of threat that can take a wide variety of forms, most of which can only be countered by deployment measures. Most DoS attacks take advantage of deep and fundamental properties of the Internet architecture, and therefore
- 36. 20 Security basics are difficult to deter with architectural solutions at the subsystem level. DoS attacks on specific network protocols, however, can be countered by ensuring the protocol designs do not incorporate bugs that enable such attacks. DoS attacks of the latter sort are discussed in the following chapters where appropriate for wireless security, but the general topic of DoS attacks requires a larger discussion than is appropriate for this text, since they are not unique to wireless systems.
- 37. 2 Network system architecture basics Wireless network operators and end users need the ability to utilize equipment from dif- ferent vendors in their networks and in customer-accessible devices. Left to themselves, vendors of network equipment and of end-user access devices such as wireless terminals tend to produce equipment that is slightly different in various ways, hindering the ability of their customers to build multi-vendor networks from interoperable equipment pieces. The key to ensuring interoperability is to have a standardized system design with clearly specified interfaces between the various network devices and well-designed, standard- ized protocols on the interfaces. The process of systematically identifying requirements and functionality and mapping that into network entities, interfaces, and standardized protocols is the key to ensuring a design that meets real-world needs and in which the pieces work together well. This requirement is generally true for network systems, but it also applies specifically to security systems. While standardization is the key to ensuring interoperability in complex multi-vendor systems, system architectures are the principal tool for guiding the design, implementa- tion, and deployment process. In this chapter, we examine the topic of network system architecture. In the next section, we discuss the role of architecture in system standard- ization in more detail. Following that, we describe a particular approach to developing a system architecture, the functional architectural approach, that is used in some wireless network standardization processes. We use this approach throughout the book to analyze existing wireless security system architectures, and ultimately in Chapter 7 to add new security architectural enhancements to existing IP systems. To illustrate how network system architectures are developed, we present a simple example of a wireless network system architecture, a key fob used to remotely open a locked car. We then specifi- cally examine how the functional architecture approach works for security systems by developing a functional architecture that provides security for the key fob. 2.1 The role of architecture in system standardization Most large wireless network systems are developed as part of a standardization process involving multiple vendors and network operations. Since the components of such systems are often manufactured by many vendors and the systems are deployed by many network operators, standardization ensures interoperability between equipment from different vendors and deployments by different operators. The first step in developing a
- 38. 22 Network system architecture basics new or enhanced standardized wireless network system is to define a system architecture. The term “architecture” is used in a variety of ways to characterize the initial output of the design process. Webster’s Dictionary defines architecture as (among other things) “a style or method of design or construction.” The approach to architecture for a large- scale wireless network system depends on the process traditionally followed by the standardization body. Most wireless standardization groups have their heritage in the traditional circuit- switched telephony architecture that was common prior to the widespread adoption of the Internet. These groups adhere to a rigorous system development process, in which formal requirements development is followed by an architectural development phase centered on meeting the requirements. The architectural development phase results in the definition of network boxes with interfaces on which the functions of interoperable protocols are specified. Protocol selection or design follows, after which a formal regression analysis is performed to ensure that the resulting system meets the initially defined requirements. The boxes and protocols are then implemented by vendors as products. While such a rigorous design process ensures accountability and fidelity with the original requirements, it is often inflexible and unable to account for changes in require- ments that come up later in the design process. The process is similar to a waterfall in which the requirements, architecture, protocol design, and implementation fall out of the standardization process like water pouring over a waterfall. Incremental modifications are inhibited, since they are not accommodated by a waterfall development model. The strong emphasis on using the requirements to rigidly structure the architecture often results in pressure by various participants in the standardization process to “game” the requirements, to ensure some advantage for their business or technical positions against their competitors. As a result, the accountability and objectivity that the process was originally intended to provide is usually considerably weakened; most of the important decisions are based on the same kinds of subjective criteria that are behind group decision making in other areas of human endeavor where interests of various parties conflict. On the other hand, the group responsible for standardizing Internet protocols, the Internet Engineering Task Force (IETF), has traditionally resisted formal architectural definitions on the Internet as a large-scale system. The rationale for this is that, for the Internet as a whole, any attempt to define a detailed architecture would constrain the development of new protocols and new applications too tightly. One of the key factors in allowing the Internet to flexibly accommodate a new generation of applications every five to ten years is the lack of a rigidly fixed architecture overall. Consequently, discussions of architecture at the level of the Internet as a whole are typically confined to a loose collection of design principles, such as those in RFC 1958 (RFC 1958), or adherence to the modified form of the OSI protocol stack (Layer 2, Network, Transport, Application) which informs the design of the IP network stack (Wikipedia, 2008a). As a result, when wireless links became available in the late 1990s, there was no global system architecture for the Internet to guide standardization of interfaces and protocols for wireless networks. As the Internet has become more complex, however, architectural definitions of well- defined subsystems have become necessary to guide protocol development and ensure
- 39. 2.2 The functional architecture approach 23 interoperability with other subsystems. A good compromise process for defining system requirements that trades off rigor against flexibility has been developed by the IETF. A set of lightweight requirements, called “goals,” is developed for the system. The goals are typically as quantitative as possible, but if it is difficult or impossible to assign numbers to what the protocol is supposed to do, a qualitative description is acceptable. The primary distinction between goals and requirements is that there is no intent to regress the final protocol design back onto the goals after the protocol design is complete. The goals are meant to be a set of flexible design guidelines. The same kinds of subjective, non-technical criteria that arise when developing formalized requirements also arise when developing goals. The difference is that because the intent of goals is not to rigidly structure the system/protocol design process, there is more room for flexibility during the design. After the goals are complete, an architecture is developed for the system. The architecture is often called a “framework,” and includes descriptions of the major network entities and how they interact at a high level. The protocol design on interfaces between network entities then follows. Not every IETF protocol design follows this process; however, it is often used when new system components are introduced. 2.2 The functional architecture approach While the frameworks developed during IETF protocol design are good at defining where interfaces between distributed network components need interoperable protocol design, such frameworks are often not very specific about what the different network entities do and what functions the protocol should perform. A functional architecture approach more accurately characterizes these points. The functional architectural approach is more formalized than the framework approach, while, at the same time, maintaining flexibility through the goals. Given a set of goals for a protocol or network system, the functional architecture approach for developing a new subsystem architecture from scratch consists of the following sequence of steps: 1. Using the requirements or goals, define a set of functions which the new subsystem must implement in order to achieve the goals. 2. Group the functions into a set of functional entities with communicating interfaces. 3. Decide which functional entities will be implemented together on a single network device and group these together; communication between the functions on the same device is handled through programmatic interfaces. 4. Define the interfaces between distributed functional entities where protocol design is required. 5. Decide which interfaces are open and require standardized protocols for interoper- ability purposes and which interfaces are closed and are therefore candidates for vendor-specific protocols. 6. Define what functional actions are communicated across the interfaces and what parameters are required by the functions and what results are returned.
- 40. 24 Network system architecture basics At the conclusion of this process, the design team should have a list of network interfaces on which standardized, interoperable protocol designs are required, a list of closed interfaces (which may be empty) where vendor-specific protocols are needed, and a list of programmatic interfaces between software modules that implement functional entities residing on the same network device. In addition, the list of functional elements and their parameters that need to communicate across a network interface provides a starting point for defining what information needs to be communicated, and therefore what the protocol must do. As a practical matter, most design exercises these days involve retrofitting new func- tionality onto existing subsystems with deployed equipment. Backward compatibility is an important constraint, since it ensures interoperability with existing network equip- ment and thereby reduces the cost of introducing the upgrade. In that case, the list of steps is slightly modified: 1. Using the requirements or goals, define a set of functions which the functionality must implement in order to achieve the goals. 2. Identify which existing network subsystems and which network entities should host the new functions. 3. Group the functions into a set of functional entities and map these onto the existing network entities. 4. Define new communicating interfaces between the new functional entities, or specify how existing interfaces need to be modified to accommodate the new functions. If the interfaces are on the same network entity, then the interfaces are programmatic. 5. Decide which new interfaces are open and require standardized protocols for inter- operability purposes and which interfaces are closed and are therefore candidates for vendor-specific protocols. 6. Define what functional actions are communicated across the interfaces and what parameters are required by the functions and what results are returned. Since most of the wireless security subsystems discussed later in the book were devel- oped as modifications to existing Internet subsystems, we follow this sequence for the examples in Chapters 4 through 7. A critical point to keep in mind when developing a functional architecture is to avoid committing to a specific protocol solution too early in the design process. Engineers like to think concretely, so there is often a temptation to include protocol solutions as func- tions rather than wait until the functional architecture is complete before beginning the protocol design. Usually it is possible to tell when a protocol solution is being proposed if someone starts talking about a function as a modification of an existing protocol, about what kind of transport protocol will be used, or about how specific messages will be encoded in protocol data units on the wire prior to the completion of step 1. Of course, if the functional architecture development is for an existing system, then existing protocols constrain the design, but these constraints should not be propagated too far nor too early into the new architectural pieces. Keeping focus on the goals and functional architecture during the initial design phase is hard, but can reap unexpected rewards later in the design process after the architecture is complete, when a consideration of a variety of
- 41. 2.2 The functional architecture approach 25 solutions implementing the architecture yields a choice that is simpler, more flexible, or more powerful than if the design had been biased toward a solution too early. Step 4 in the functional architectural process involves making a choice about which interfaces to make programmatic and which to make network-based. The technical criteria that constrain the classification of interfaces as programmatic or network-based often involve performance, access to particular data, or the need for replication and distribution. Performance constraints may dictate whether an interface is programmatic or network-based because protocol exchanges between network devices can require milliseconds or more depending on the network distance between the devices, whereas programmatic interfaces typically require less than a millisecond on modern processors. If a cryptographic algorithm is especially computation-intensive, a network interface may be necessary if the function involving that algorithm is located on a specialized device with dedicated cryptographic hardware. If a particular functional entity requires access to a large amount of data, a programmatic interface may be necessary if the data resides in main memory or in a database on the local disk. If a particular functional entity needs to be replicated at various points in a network, or if the functional entity needs to be distributed to provide reliability and robustness in the face of network failures, a network-based interface may be necessary between the different instances of the functional entity and/or between the functional entity and others. The difficult part of developing a functional architecture is deciding how to clas- sify the network-based interfaces as open or closed, which is step 5 in the functional architecture process. The technical aspects of system design often do not constrain the decision enough to point to an obvious choice, so non-technical criteria, such as business considerations, often play a major role in deciding which interfaces to open and which to close. If the participants in the design process are willing to honor the technical constraints where they exist, then non-technical criteria are often useful where technical constraints do not exist, since the satisfaction of such non-technical criteria can make vendors and network operators more interested in actually deploying a protocol or system. While it might seem inappropriate to take such considerations into account when doing an engineering design, the reality is that they heavily influence the kinds of wireless network architectures that are standardized and therefore the kinds of protocols that are developed. Network operators typically like protocol interfaces to be open because they would like the widest possible choice of interoperable hardware, in order to facilitate competition and thus (hopefully) lower prices. Vendors, on the other hand, like closed interfaces because they can be used to lock customers into purchasing complete network systems and not just single boxes. As a result, sometimes the decision whether to make an interface open or closed is governed by a tussle between operators and vendors in the design and standardization process. If the interface is between new network entities and older ones, and the interface to the older ones is either standardized or proprietary, then the decision is clear – the protocol on the older interface must be matched on the new network device. The wireless interface between network equipment such as access points and base stations and end-user equipment such as handsets and interface cards is usually open, since even though there are vendors that manufacture both end-user equipment
- 42. 26 Network system architecture basics and network equipment, the vendors want their end-user equipment to interoperate with other vendors’ network equipment. Closed interfaces are often appropriate where the collection of functions on the interface is thought to be incomplete at the time the initial design is done. Making the interface closed gives vendors an opportunity to experiment with various extensions, which can be standardized later if some prove useful beyond the implementing vendor’s application. The danger with closed interfaces is that multiple, incompatible versions of the interface can proliferate, making a later consolidation necessary for achieving interoperability. This situation can hinder initial deployment. 2.3 Example functional architecture for a simple wireless system In this section, we develop a functional architecture for a simple wireless system: the wireless key fob, offered with many late-model automobiles. The key fob allows a driver to open the doors remotely while still walking to the car. On the face of it, using an architectural approach to design a system which is so simple and really well known from everyday use might seem a little silly, but the simplicity and familiarity has advantages. Simplicity means that we can discuss the architectural approach in a couple of pages and not get bogged down in excessive detail. The familiarity means that goals of the system and the functionality are fairly clear. 2.3.1 System goals For such a familiar system, the system goals should be well known. The system should: r allow the user to remotely lock the car r allow the user to remotely unlock the driver’s side door r allow the user to remotely unlock all doors r allow the user to remotely activate the horn and headlights to help the user find the car r cause the horn and headlight display to cease on activation of any other control or opening the doors with the physical key, if the horn and headlight function has been activated. These goals are very high level, general, and also qualitative. Perhaps after review some quantitative constraints seem desirable; for example, the maximum amount of time between when the user activates a function and when the car responds, or a maximum duration for the “panic button” functionality in the fourth goal to avoid annoying neighbors by long periods of unconstrained honking. But the goals in the above list should be sufficient for demonstrating the next step, determining the system functions. 2.3.2 Required system functions Based on the system goals, we can now draw up a list of system functions. Here is the list (the functions are numbered for further reference below):
- 43. 2.3 Example functional architecture 27 1. Activate signaling upon button 1 press to lock car. 2. Receive signal to lock car. 3. Send lock command on car’s command bus to all doors. 4. Activate signaling upon button 2 press to unlock driver’s side door. 5. Receive signaling to unlock driver’s side door. 6. Send unlock command on car’s command bus to driver’s side door. 7. Activate signaling upon button 3 press to unlock all doors. 8. Receive signaling to unlock all doors. 9. Send unlock command on car’s command bus to all doors. 10. Activate “panic button” signaling upon panic button press to beep and flash. 11. Receive “panic button” activation signaling. 12. Send beep and flash command on car’s command bus. 13. Activate signaling upon any button press to deactivate “panic button” if “panic button” is currently active. 14. Receive “panic button” deactivation signaling. 15. Send beep and flash termination command on car’s command bus. 2.3.3 System functional entities Since we are modeling an existing system, the network entities in the system are clear: the key fob and the car. The functional entities need to be defined in a way that fits into these network entities. The system functions can be grouped into three functional entities. They are: r an “Activate Signaling” functional entity supporting Functions 1, 4, 7, 10, and 13 from the above list; r a “Receive Signaling” functional entity supporting Functions 2, 5, 8, 11, and 14 from the above list; r a “Command Origination” functional entity supporting Functions 3, 6, 9, 12, and 15 from the above list. The basis for grouping these functions is the similar role the grouped functions play in implementing the goals and the network entity on which they are implemented. Because Functions 1, 4, 7, 10, and 12 are all user-facing functions, they are implemented together on the key fob. Functions 2, 5, 8, 11, and 14 are involved in receiving and interpreting the commands from the user interface, and translating command parameters into internal data structures that can be used to carry out the commands. They are implemented together on the car. Functions 3, 6, 9, 12, and 15 translate internal data structures and command flow from user interface reception to commands on the car’s command bus. They are also implemented on the car. 2.3.4 Selection of interface types Interfaces between the functional entities and their type (network-based or program- matic) are determined by where the entities are implemented:
- 44. 28 Network system architecture basics r N1 – The Activate Signaling entity is implemented on the key fob which also supports the user interface for the system. The Receive Signaling entity is located in the car. The interface between the two entities is a wireless protocol interface. r P1 – The Command Origination entity has no interface with the Activate Signal- ing entity, just with the Receive Signaling entity, and it too is implemented in the car. In addition, the Command Origination entity and the Receive Signaling entity communicate so the interface between them should be a programmatic interface. The next step is deciding which interfaces should be open and which should be closed. Whether or not N1 should be an open interface, for which the specification is standardized and published, depends on the business goals for the product. If there are currently no standards for wireless remote key entry devices, or the car manufacturer wants to keep control over the protocol for business or other reasons, the interface might be kept proprietary. If, on the other hand, the car manufacturer wants to enable an aftermarket business in remote car door opening devices, perhaps for a “convergence” device that supports both car and garage door opening, then the interface should be standardized and published. 2.3.5 Functional architecture Figure 2.1 shows the functional architecture for the remote car key system. There are two network entities, the remote entry key fob and a (possibly software) module on the car that implements the key fob commands. 2.4 Functional architecture for network security systems The functional architecture approach to network system design described above is quite general. Applying it specifically to security systems requires a few specializations of the approach. For security systems, the security goals are typically derived from the threat analysis. Since the security system is intended to counter threats uncovered dur- ing the threat analysis, each specific threat should generate a goal involved in countering the threat. There may be additional goals for the security system that are unrelated to threats but necessary for other reasons. For example, if the security system inter- faces with other network subsystems and protocols, goals constraining the design to accommodate the interaction between the security system and other components are necessary. In addition, the functional architecture of the network subsystem for which the security system is being designed may constrain the security architecture in other ways, since the security architecture must be designed to address threats to the network architecture. A good threat analysis should be specific enough to constrain the definition of security system functions, but not so specific as to limit the applicability of the functions too sharply. For example, threats to confidentiality may arise from a variety of sources – pas- sive eavesdroppers, active attackers, etc. Listing each of these as a separate threat might
- 45. 2.4 Network security architecture 29 Activate Signaling • Activate lock all on button 1 press • Activate driver’s side unlock on button 2 press • Activate unlock all on button 3 press • Activate ‘‘panic button” on button 4 press • Deactivate ‘‘panic button’’ if any other button pressed and panic button Receive Signaling • Receive lock all on button 1 press • Receive driver’s side unlock on button 2 press • Receive unlock all on button 3 press • Receive ‘‘panic button’’ on button 4 press • Receive deactivate ‘‘panic button’’ if any other button pressed and panic button N1 Command Origination • Send lock command on car bus • Send unlock driver’s side on car bus • Send unlock all on car bus • Send start beep and flash on car bus • Send stop beep and flash on car bus P1 Figure 2.1 Network reference architecture for remote key system lead to separate functions for confidentiality to counter each threat. Unless the nature of the threat to confidentiality is fundamentally different, all threats to confidentiality should be grouped under the same heading. Fundamental differences between threats within the same class of threat are usually evident when there are basic differences in the security prerequisites, for example, if the pre-provisioned cryptomaterial (keys, certificates, passwords, etc.) must be different or if different algorithms must be used. Sometimes, these differences are generated by backward compatibility requirements necessary to accommodate pre-existing security system components. After the threats have been identified, the following steps result in a security archi- tecture: r Select a security service from those listed in Chapter 1 to mitigate each threat. r If any supporting systems are needed, select supporting systems from those listed in Chapter 1. If supporting systems are available from existing security system compo- nents, then use them. r Develop functions around the security services and the supporting systems. r Define functional entities and interfaces. For example, suppose there is a threat to a communication session between two parties involving third-party eavesdropping. A function included to counter that threat involves data confidentiality protection. A supporting system for key distribution may be required if the existing security systems do not have key distribution support. After the functions
- 46. 30 Network system architecture basics have been defined, functional entities and interfaces between them and between pro- grammatic components are defined to complete the functional architecture. Often, the choice of functional entities and interfaces is dictated by the overall network system architecture or by existing network entities. For example, suppose there is a requirement for confidentiality protection between two communicating network entities in the network system architecture. Rather than define a new network entity, the security architecture simply adds additional functions to the existing communicating entities. In the process of designing the security architecture, certain threats may be identified that require modifications to the network architecture. The process is not linear, iteration is sometimes necessary to ensure that the network architecture supports the security architecture. While it is generally best not to specify cryptographic algorithms at the functional architecture stage if at all possible, other requirements independent from the security requirements usually dictate what particular type of cryptographic algorithm to use. In Chapter 3, we discuss specific types of cryptographic algorithms with examples that are widely used in wireless Internet protocols. The network architecture for the subsystem under design may dictate what type of cryptographic algorithm is best. For example, a network protocol that involves a wireless terminal with no prior business or user relationship interacting with the access network may require public key cryptography rather than shared key cryptography because the two sides do not have a preshared secret. These considerations require that the requirements of the cryptographic algorithms need to be incorporated into the security system functional architecture. 2.5 Example functional architecture for a wireless security system As is typical, we developed the network architecture first for the key fob. In this section, we apply the process described above to develop a security architecture for the key fob. The security architecture does not add any additional network entities, but it does require some additional functions and functional entities on both the car and the key fob itself. Also, we assume there are no existing security subsystems, though, in practice, the car may support some security systems to control access to critical engine components over the car’s bus. The sections below step through the security architecture development process. 2.5.1 Identify the threats The communication between the key fob and the car is the primary target of interest for an attacker, and is the most dangerous because the attacker can access it while some distance away from the owner or the car. While it is possible for an attacker to target the car or the key fob, typically the key fob will be in the owner’s possession and the car will be protected by locking. Attackers can obtain access to either only if they access the physical object. Below, we examine each threat category from Chapter 1 for possible attacks on the fob to car communication.
- 47. 2.5 Wireless security architecture 31 r Replay attack: The attacker replays captured traffic in order to cause the car to unlock, thereby gaining entry to the car. This is clearly a threat, though in order to actually capture the traffic, the attacker needs to be within a short (and thereby possibly visible) distance of the car owner, because the range of the key fob is limited. r Eavesdropping: An eavesdropper on the fob to car communication is able to obtain information about when the car owner locks or unlocks the car. Because the radius of communication is typically short, the attacker has to be within a short distance of the car owner in order to obtain this information. Since the attacker could also determine the owner’s actions by simply watching what the owner is doing, an eavesdropping attack alone on the fob to car communication is probably not a serious problem. r Spoofing: If the attacker can spoof traffic from the key fob, unauthorized access to the car can be obtained. A spoofing attack is particularly serious if it can be launched by an attacker that has never had access to any communications between the key fob and the car, because this would allow the attacker to perpetrate the attack without ever being in a potentially vulnerable position near the key fob, where its presence could be detected. This is clearly the most serious threat to the key fob system. r Man-in-the-middle attacks: A man-in-the-middle attack occurs if the attacker can position itself between the key fob and the car in the communication. Depending on what occurs with the traffic, the man in the middle attack could be more or less of a threat. The attacker could use its position to launch a denial-of-service attack, effectively preventing the owner from opening the car. The attacker could analyze the intercepted traffic in order to try to crack security, or could replay the traffic in order to gain access to the car. Of these, the replay attack is probably the most important, as discussed above. Denial-of-service attacks are discussed in the next paragraph. While traffic analysis is clearly a problem, in this case, the attacker cannot derive much useful information from the traffic other than what is already known, unless the cryptographic algorithms used to secure the traffic are insufficiently robust. r Denial-of-service attack: The attacker can launch a denial-of-service attack by captur- ing and replaying valid traffic, as a man in the middle. If the protocol or implementation has any bugs, this could lead to crashing the car’s operating system or causing the key fob to lock up. These kinds of problems can be addressed by carefully designing the protocol implementation to avoid buffer overflows and other obvious sources of security problems, and then stress-testing the implementation to help identify bugs. Of course, there are easier ways for the attacker to launch a denial-of-service attack, for example, turning on a radio noise generator on the frequency of the key fob. 2.5.2 Select security services to mitigate the threats The threat analysis reveals that the two most serious threats involve spoofing. The most serious threat is an attack in which the attacker can fabricate a spoofing key fob without having access to any network traffic and thereby open the locked car. The next most serious threat is when the attacker can insert themselves as a man in the middle, then gather traffic that will allow opening the car at a later date either by replaying the traffic
- 48. 32 Network system architecture basics or by synthesizing a new message. In contrast, threats that may require confidentiality seem to be of lesser concern. Due to the short range of the key fob, the attacker must be near the key fob owner, so the attacker could derive exactly the same information by simply watching the owner’s actions (getting into the car after having opened it, etc.). DoS attacks on the protocol are similarly of lesser concern, since the attacker could mount an attack more effectively by simply starting up a radio noise generator. Nevertheless, good protocol engineering and testing is necessary to ensure that obvious DoS attack bugs – like buffer overflows – don’t creep into the implementation, thereby allowing an attacker to crash the car’s operating system. The spoofing attacks suggest that the key fob architecture requires three security services: r identity authentication to identify that the key fob is, in fact, authorized to act as a key for the car; r anti-replay protection to prevent the attacker from replaying legitimate messages to open the door; r data origin authentication to ensure that the messages originate from the authorized key fob. In practice, since the key fob protocol is a one-shot protocol (one message is sent and received per action), the protocol does not involve session establishment, allowing the identity management and data origin authentication to be combined. Each message is a separate session and therefore no session-specific key provisioning is required. 2.5.3 Select necessary supporting systems The requirement for terminal and data origin authentication generates an additional requirement for credential provisioning and key management between the car and the key fob at some point prior to the key fob’s use as a key. This procedure is outside the basic key fob network architecture described above. It could be done by pre-provisioning credentials on the key fob at the factory, or it could be done as part of an initial “introduction” between the key fob and the car, in which the user or possibly the car dealer performs some kind of activation procedure on the key fob and car to program both with the proper credentials. Either case requires functions in the security architecture to provision the credentials. 2.5.4 Develop functions around services and supporting systems Applying the solution approaches to the architecture in Figure 2.1 leads to the following set of functions on the key fob: r Key Fob Credential Configuration – this function runs prior to the key fob being used as a key and configures the key fob with credentials whereby the key fob can authenticate itself with the car.
- 49. 2.5 Wireless security architecture 33 Activate Signaling • Inset authentication and anti-replay protection Receive Signaling • Validate authentication and anti-replay protection SN1 Credential Configuration Agent • Configure key fob with authentication credentials CS1 • Configure car with authentication credentials CS2 Figure 2.2 Security architecture for the key fob example r Signaling Authentication and Anti-Replay Protection – this function insets authenti- cation and anti-replay protection on the messages from the key fob to the car. The matching functions on the car are: r Car Credential Configuration – this function runs prior to the key fob being used as a key and configures the car with a set of matching credentials allowing the car to authenticate the key fob. r Signaling Authentication and Anti-Replay Verification – this function verifies the authentication and anti-replay protection on signaling from the key fob, rejecting any signaling that does not pass verification. In addition, a function is necessary for co-ordinating the configuration of credentials on both the car and the key fob: r Credential Configuration Co-ordination – this function is responsible for co-ordinating the pre-use configuration of matching authentication credentials on the key fob and car. 2.5.5 Define network entities and interfaces Figure 2.2 contains a functional architecture diagram. The security architecture adds one additional functional entity to the architecture:
- 50. Another Random Scribd Document with Unrelated Content
- 51. Project Gutenberg™ eBooks are often created from several printed editions, all of which are confirmed as not protected by copyright in the U.S. unless a copyright notice is included. Thus, we do not necessarily keep eBooks in compliance with any particular paper edition. Most people start at our website which has the main PG search facility: www.gutenberg.org. This website includes information about Project Gutenberg™, including how to make donations to the Project Gutenberg Literary Archive Foundation, how to help produce our new eBooks, and how to subscribe to our email newsletter to hear about new eBooks.
- 52. Welcome to Our Bookstore - The Ultimate Destination for Book Lovers Are you passionate about books and eager to explore new worlds of knowledge? At our website, we offer a vast collection of books that cater to every interest and age group. From classic literature to specialized publications, self-help books, and children’s stories, we have it all! Each book is a gateway to new adventures, helping you expand your knowledge and nourish your soul Experience Convenient and Enjoyable Book Shopping Our website is more than just an online bookstore—it’s a bridge connecting readers to the timeless values of culture and wisdom. With a sleek and user-friendly interface and a smart search system, you can find your favorite books quickly and easily. Enjoy special promotions, fast home delivery, and a seamless shopping experience that saves you time and enhances your love for reading. Let us accompany you on the journey of exploring knowledge and personal growth! ebookgate.com