(BQ) Part 1 book Distributed systems Concepts and design has contents Security, distributed file systems, name services, time and global states, coordination and agreement, transactions and concurrency control, distributed transactions, replication, mobile and ubiquitous computing, distributed multimedia systems,... and other contents.
11 SECURITY 11.1 11.2 11.3 11.4 11.5 11.6 11.7 Introduction Overview of security techniques Cryptographic algorithms Digital signatures Cryptography pragmatics Case studies: Needham–Schroeder, Kerberos, TLS, 802.11 WiFi Summary There is a pervasive need for measures to guarantee the privacy, integrity and availability of resources in distributed systems Security attacks take the forms of eavesdropping, masquerading, tampering and denial of service Designers of secure distributed systems must cope with exposed service interfaces and insecure networks in an environment where attackers are likely to have knowledge of the algorithms used and to deploy computing resources Cryptography provides the basis for the authentication of messages as well as their secrecy and integrity; carefully designed security protocols are required to exploit it The selection of cryptographic algorithms and the management of keys are critical to the effectiveness, performance and usability of security mechanisms Public-key cryptography makes it easy to distribute cryptographic keys but its performance is inadequate for the encryption of bulk data Secret-key cryptography is more suitable for bulk encryption tasks Hybrid protocols such as Transport Layer Security (TLS) establish a secure channel using public-key cryptography and then use it to exchange secret keys for use in subsequent data exchanges Digital information can be signed, producing digital certificates Certificates enable trust to be established among users and organizations The chapter concludes with case studies on the approaches to security system design and the security mechanisms deployed in Kerberos, TLS/SSL and 802.11 WiFi 463 464 CHAPTER 11 SECURITY 11.1 Introduction In Section 2.4.3 we introduced a simple model for examining the security requirements in distributed systems We concluded that the need for security mechanisms in distributed systems arises from the desire to share resources (Resources that are not shared can generally be protected by isolating them from external access.) If we regard shared resources as objects, then the requirement is to protect any processes that encapsulate shared objects and any communication channels that are used to interact with them against all conceivable forms of attack The model introduced in Section 2.4.3 provides a good starting point for the identification of security requirements It can be summarized as follows: • Processes encapsulate resources (both programming language–level objects and system-defined resources) and allow clients to access them through interfaces Principals (users or other processes) are authorized to operate on resources Resources must be protected against unauthorized access (Figure 2.17) • Processes interact through a network that is shared by many users Enemies (attackers) can access the network They can copy or attempt to read any message transmitted through the network and they can inject arbitrary messages, addressed to any destination and purporting to come from any source, into the network (Figure 2.18) The need to protect the integrity and privacy of information and other resources belonging to individuals and organizations is pervasive in both the physical and the digital world It arises from the desire to share resources In the physical world, organizations adopt security policies that provide for the sharing of resources within specified limits For example, a company may permit entry to its buildings only to its employees and accredited visitors A security policy for documents may specify groups of employees who can access classes of documents, or it may be defined for individual documents and users Security policies are enforced with the help of security mechanisms For example, access to a building may be controlled by a reception clerk, who issues badges to accredited visitors, and enforced by a security guard or by electronic door locks Access to paper documents is usually controlled by concealment and restricted distribution In the electronic world, the distinction between security policies and mechanisms is equally important; without it, it would be difficult to determine whether a particular system was secure Security policies are independent of the technology used, just as the provision of a lock on a door does not ensure the security of a building unless there is a policy for its use (for example, that the door will be locked whenever nobody is guarding the entrance) The security mechanisms that we describe here not in themselves ensure the security of a system In Section 11.1.2, we outline the requirements for security in various simple electronic commerce scenarios, illustrating the need for policies in that context The provision of mechanisms for the protection of data and other resources in distributed systems while allowing interactions between computers that are permitted by security policies is the concern of this chapter The mechanisms that we shall describe are designed to enforce security policies against the most determined attacks SECTION 11.1 INTRODUCTION 465 The role of cryptography • Digital cryptography provides the basis for most computer security mechanisms, but it is important to note that computer security and cryptography are distinct subjects Cryptography is the art of encoding information in a format that only the intended recipients can decode Cryptography can also be employed to provide proof of the authenticity of information, in a manner analogous to the use of signatures in conventional transactions Cryptography has a long and fascinating history The military need for secure communication and the corresponding need of an enemy to intercept and decrypt it led to the investment of much intellectual effort by some of the best mathematical brains of their time Readers interested in exploring this history will find absorbing reading in books on the topic by David Kahn [Kahn 1967, 1983, 1991] and Simon Singh [Singh 1999] Whitfield Diffie, one of the inventors of public-key cryptography, has written with firsthand knowledge on the recent history and politics of cryptography [Diffie 1988, Diffie and Landau 1998] It is only in recent times that cryptography has emerged from the wraps previously placed on it by the political and military establishments that used to control its development and use It is now the subject of open research by a large and active community, with the results presented in many books, journals and conferences The publication of Schneier’s book Applied Cryptography [Schneier 1996] was a milestone in the opening up of knowledge in the field It was the first book to publish many important algorithms with source code – a courageous step, because when the first edition appeared in 1994 the legal status of such publication was unclear Schneier’s book remains the definitive reference on most aspects of modern cryptography A more recent book co-authored by Schneier [Ferguson and Schneier 2003] provides an excellent introduction to computer cryptography and a discursive overview of virtually all the important algorithms and techniques in current use, including several published since Schneier’s earlier book In addition, Menezes et al [1997] provide a good practical handbook with a strong theoretical basis and the Network Security Library [www.secinf.net] is an excellent online source of practical knowledge and experience Ross Anderson’s Security Engineering [Anderson 2008] is also outstanding It is replete with object lessons on the design of secure systems, drawn from real-world situations and system security failures The new openness is largely a result of the tremendous growth of interest in nonmilitary applications of cryptography and the security requirements of distributed computer systems, which has led to the existence for the first time of a self-sustaining community of cryptographic researchers outside the military domain Ironically, the opening of cryptography to public access and use has resulted in a great improvement in cryptographic techniques, both in their strength to withstand attacks by enemies and in the convenience with which they can be deployed Public-key cryptography is one of the fruits of this openness As another example, we note that the DES encryption algorithm that was adopted and used by the US military and government agencies was initially a military secret Its eventual publication and successful efforts to crack it resulted in the development of much stronger secret-key encryption algorithms Another useful spin-off has been the development of a common terminology and approach An example of the latter is the adoption of a set of familiar names for protagonists (principals) involved in the transactions that are to be secured The use of 466 CHAPTER 11 SECURITY Figure 11.1 Familiar names for the protagonists in security protocols Alice Bob Carol Dave Eve Mallory Sara First participant Second participant Participant in three- and four-party protocols Participant in four-party protocols Eavesdropper Malicious attacker A server familiar names for principals and attackers helps to clarify and bring to life descriptions of security protocols and potential attacks on them, which aids in identifying their weaknesses The names shown in Figure 11.1 are used extensively in the security literature and we use them freely here We have not been able to discover their origins; the earliest occurrence of which we are aware is in the original RSA public-key cryptography paper [Rivest et al 1978] An amusing commentary on their use can be found in Gordon [1984] 11.1.1 Threats and attacks Some threats are obvious – for example, in most types of local network it is easy to construct and run a program on a connected computer that obtains copies of the messages transmitted between other computers Other threats are more subtle – if clients fail to authenticate servers, a program might install itself in place of an authentic file server and thereby obtain copies of confidential information that clients unwittingly send to it for storage In addition to the danger of loss or damage to information or resources through direct violations, fraudulent claims may be made against the owner of a system that is not demonstrably secure To avoid such claims, the owner must be in a position to disprove the claim by showing that the system is secure against such violations or by producing a log of all of the transactions for the period in question A common instance is the ‘phantom withdrawal’ problem in automatic cash dispensers (teller machines) The best answer that a bank can supply to such a claim is to provide a record of the transaction that is digitally signed by the account holder in a manner that cannot be forged by a third party The main goal of security is to restrict access to information and resources to just those principals that are authorized to have access Security threats fall into three broad classes: Leakage: Refers to the acquisition of information by unauthorized recipients Tampering: Refers to the unauthorized alteration of information Vandalism: Refers to interference with the proper operation of a system without gain to the perpetrator SECTION 11.1 INTRODUCTION 467 Attacks on distributed systems depend upon obtaining access to existing communication channels or establishing new channels that masquerade as authorized connections (We use the term channel to refer to any communication mechanism between processes.) Methods of attack can be further classified according to the way in which a channel is misused: Eavesdropping: Obtaining copies of messages without authority Masquerading: Sending or receiving messages using the identity of another principal without their authority Message tampering: Intercepting messages and altering their contents before passing them on to the intended recipient The man-in-the-middle attack is a form of message tampering in which an attacker intercepts the very first message in an exchange of encryption keys to establish a secure channel The attacker substitutes compromised keys that enable them to decrypt subsequent messages before reencrypting them in the correct keys and passing them on Replaying: Storing intercepted messages and sending them at a later date This attack may be effective even with authenticated and encrypted messages Denial of service: Flooding a channel or other resource with messages in order to deny access for others These are the dangers in theory, but how are attacks carried out in practice? Successful attacks depend upon the discovery of loopholes in the security of systems Unfortunately, these are all too common in today’s systems, and they are not necessarily particularly obscure Cheswick and Bellovin [1994] identify 42 weaknesses that they regard as posing serious risks in widely used Internet systems and components They range from password guessing to attacks on the programs that perform the Network Time Protocol or handle mail transmission Some of these have led to successful and well-publicized attacks [Stoll 1989, Spafford 1989], and many of them have been exploited for mischievous or criminal purposes When the Internet and the systems that are connected to it were designed, security was not a priority The designers probably had no conception of the scale to which the Internet would grow, and the basic design of systems such as UNIX predates the advent of computer networks As we shall see, the incorporation of security measures needs to be carefully thought out at the basic design stage, and the material in this chapter is intended to provide the basis for such thinking We focus on the threats to distributed systems that arise from the exposure of their communication channels and their interfaces For many systems, these are the only threats that need to be considered (other than those that arise from human error – security mechanisms cannot guard against a badly chosen password or one that is carelessly disclosed) But for systems that include mobile programs and systems whose security is particularly sensitive to information leakage, there are further threats Threats from mobile code • Several recently developed programming languages have been designed to enable programs to be loaded into a process from a remote server and then executed locally In that case, the internal interfaces and objects within an executing process may be exposed to attack by mobile code 468 CHAPTER 11 SECURITY Java is the most widely used language of this type, and its designers paid considerable attention to the design and construction of the language and the mechanisms for remote loading in an effort to restrict the exposure (the sandbox model of protection against mobile code) The Java virtual machine (JVM) is designed with mobile code in view It gives each application its own environment in which to run Each environment has a security manager that determines which resources are available to the application For example, the security manager might stop an application reading and writing files or give it limited access to network connections Once a security manager has been set, it cannot be replaced When a user runs a program such as a browser that downloads mobile code to be run locally on their behalf, they have no very good reason to trust the code to behave in a responsible manner In fact, there is a danger of downloading and running malicious code that removes files or accesses private information To protect users against untrusted code, most browsers specify that applets cannot access local files, printers or network sockets Some applications of mobile code are able to assume various levels of trust in downloaded code In this case, the security managers are configured to provide more access to local resources The JVM takes two further measures to protect the local environment: The downloaded classes are stored separately from the local classes, preventing them from replacing local classes with spurious versions The bytecodes are checked for validity Valid Java bytecode is composed of Java virtual machine instructions from a specified set The instructions are also checked to ensure that they will not produce certain errors when the program runs, such as accessing illegal memory addresses The security of Java has been the subject of much subsequent investigation, in the course of which it became clear that the original mechanisms adopted were not free of loopholes [McGraw and Felden 1999] The identified loopholes were corrected and the Java protection system was refined to allow mobile code to access local resources when authorized to so [java.sun.com V] Despite the inclusion of type-checking and code-validation mechanisms, the security mechanisms incorporated into mobile code systems not yet produce the same level of confidence in their effectiveness as those used to protect communication channels and interfaces This is because the construction of an environment for execution of programs offers many opportunities for error, and it is difficult to be confident that all have been avoided Volpano and Smith [1999] have pointed out that an alternative approach, based on proofs that the behaviour of mobile code is sound, might offer a better solution Information leakage • If the transmission of a message between two processes can be observed, some information can be gleaned from its mere existence – for example, a flood of messages to a dealer in a particular stock might indicate a high level of trading in that stock There are many more subtle forms of information leakage, some malicious and others arising from inadvertent error The potential for leakage arises whenever the results of a computation can be observed Work was done on the prevention of this type of security threat in the 1970s [Denning and Denning 1977] The approach taken is to assign security levels to information and channels and to analyze the flow of information SECTION 11.1 INTRODUCTION 469 into channels with the aim of ensuring that high-level information cannot flow into lower-level channels A method for the secure control of information flows was first described by Bell and LaPadula [1975] The extension of this approach to distributed systems with mutual distrust between components is the subject of recent research [Myers and Liskov 1997] 11.1.2 Securing electronic transactions Many uses of the Internet in industry, commerce and elsewhere involve transactions that depend crucially on security For example: Email: Although email systems did not originally include support for security, there are many uses of email in which the contents of messages must be kept secret (for example, when sending a credit card number) or the contents and sender of a message must be authenticated (for example when submitting an auction bid by email) Cryptographic security based on the techniques described in this chapter is now included in many mail clients Purchase of goods and services: Such transactions are now commonplace Buyers select goods and pay for them via the Web and the goods are delivered through an appropriate delivery mechanism Software and other digital products (such as recordings and videos) can be delivered by downloading Tangible goods such as books, CDs and almost every other type of product are also sold by Internet vendors; these are supplied via a delivery service Banking transactions: Electronic banks now offer users virtually all of the facilities provided by conventional banks They can check their balances and statements, transfer money between accounts, set up regular automatic payments and so on Micro-transactions: The Internet lends itself to the supply of small quantities of information and other services to many customers Most web pages currently can be viewed without charge, but the development of the Web as a high-quality publishing medium surely depends upon the ability of information providers to obtain payments from consumers of the information Voice and videoconferencing on the Internet is currently also free, but it is charged for when a telephone network is also involved The price for such services may amount to only a fraction of a cent, and the payment overheads must be correspondingly low In general, schemes based on the involvement of a bank or credit card server for each transaction cannot achieve this Transactions such as these can be safely performed only when they are protected by appropriate security policies and mechanisms A purchaser must be protected against the disclosure of credit codes (card numbers) during transmission and against fraudulent vendors who obtain payment with no intention of supplying the goods Vendors must obtain payment before releasing the goods, and for downloadable products they must ensure that only paying customers obtain the data in a usable form The required protection must be achieved at a cost that is reasonable in comparison with the value of the transaction 470 CHAPTER 11 SECURITY Sensible security policies for Internet vendors and buyers lead to the following requirements for securing web purchases: Authenticate the vendor to the buyer, so that the buyer can be confident that they are in contact with a server operated by the vendor with whom they intended to deal Keep the buyer’s credit card number and other payment details from falling into the hands of any third party and ensure that they are transmitted unaltered from the buyer to the vendor If the goods are in a form suitable for downloading, ensure that their content is delivered to the buyer without alteration and without disclosure to third parties The identity of the buyer is not normally required by the vendor (except for the purpose of delivering the goods, if they are not downloaded) The vendor will wish to check that the buyer has sufficient funds to pay for the purchase, but this is usually done by demanding payment from the buyer’s bank before delivering the goods The security needs of banking transactions using an open network are similar to those for purchase transactions, with the buyer as the account holder and the bank as the vendor, but there there is a fourth requirement as well: Authenticate the identity of the account holder to the bank before giving them access to their account Note that in this situation, it is important for the bank to ensure that the account holder cannot deny that they participated in a transaction Non-repudiation is the name given to this requirement In addition to the above requirements, which are dictated by security policies, there are some system requirements These arise from the very large scale of the Internet, which makes it impractical to require buyers to enter into special relationships with vendors (by registering encryption keys for later use, etc.) It should be possible for a buyer to complete a secure transaction with a vendor even if there has been no previous contact between buyer and vendor and without the involvement of a third party Techniques such as the use of ‘cookies’ – records of previous transactions stored on the user’s client host – have obvious security weaknesses; desktop and mobile hosts are often located in insecure physical environments Because of the importance of security for Internet commerce and the rapid growth in Internet commerce, we have chosen to illustrate the use of cryptographic security techniques by describing in Section 11.6 the de facto standard security protocol used in most electronic commerce – Transport Layer Security (TLS) A description of Millicent, a protocol specifically designed for micro-transactions, can be found at www.cdk5.net/security Internet commerce is an important application of security techniques, but it is certainly not the only one It is needed wherever computers are used by individuals or organizations to store and communicate important information The use of encrypted email for private communication between individuals is a case in point that has been the subject of considerable political discussion We refer to this debate in Section 11.5.2 SECTION 11.1 INTRODUCTION 471 11.1.3 Designing secure systems Immense strides have been made in recent years in the development of cryptographic techniques and their application, yet designing secure systems remains an inherently difficult task At the heart of this dilemma is the fact that the designer’s aim is to exclude all possible attacks and loopholes The situation is analogous to that of the programmer whose aim is to exclude all bugs from their program In neither case is there a concrete method to ensure this goal is met during the design One designs to the best available standards and applies informal analysis and checks Once a design is complete, formal validation is an option Work on the formal validation of security protocols has produced some important results [Lampson et al 1992, Schneider 1996, Abadi and Gordon 1999] A description of one of the first steps in this direction, the BAN logic of authentication [Burrows et al 1990], and its application can be found at www.cdk5.net/security Security is about avoiding disasters and minimizing mishaps When designing for security it is necessary to assume the worst The box on page 472 shows a set of useful assumptions and design guidelines These assumptions underly the thinking behind the techniques that we describe in this chapter To demonstrate the validity of the security mechanisms employed in a system, the system’s designers must first construct a list of threats – methods by which the security policies might be violated – and show that each of them is prevented by the mechanisms employed This demonstration may take the form of an informal argument or, better, a logical proof No list of threats is likely to be exhaustive, so auditing methods must also be used in security-sensitive applications to detect violations These are straightforward to implement if a secure log of security-sensitive system actions is always recorded with details of the users performing the actions and their authority A security log will contain a sequence of timestamped records of users’ actions At a minimum the records will include the identity of a principal, the operation performed (e.g., delete file, update accounting record), the identity of the object operated on and a timestamp Where particular violations are suspected, the records may be extended to include physical resource utilization (network bandwidth, peripherals), or the logging process may be targeted at operations on particular objects Subsequent analysis may be statistical or search-based Even when no violations are suspected, the statistics may be compared over time to help to discover any unusual trends or events The design of secure systems is an exercise in balancing costs against the threats The range of techniques that can be deployed for protecting processes and securing interprocess communication are strong enough to withstand almost any attack, but their use incurs expense and inconvenience: • A cost (in terms of computational effort and network usage) is incurred for their use The costs must be balanced against the threats • Inappropriately specified security measures may exclude legitimate users from performing necessary actions Such trade-offs are difficult to identify without compromising security and may seem to conflict with the advice in the first paragraph of this subsection, but the strength of security techniques required can be quantified and techniques can be selected based on 472 CHAPTER 11 SECURITY the estimated cost of attacks The relatively low-cost techniques employed in the Millicent protocol, described at www.cdk5.net/security provide an example As an illustration of the difficulties and mishaps that can arise in the design of secure systems, we review difficulties that arose with the security design originally incorporated in the IEEE 802.11 WiFi networking standard in Section 11.6.4 11.2 Overview of security techniques The purpose of this section is to introduce the reader to some of the more important techniques and mechanisms for securing distributed systems and applications Here we describe them informally, reserving more rigorous descriptions for Sections 11.3 and 11.4 We use the familiar names for principals introduced in Figure 11.1 and the notations for encrypted and signed items shown in Figure 11.2 Worst-case assumptions and design guidelines Interfaces are exposed: Distributed systems are composed of processes that offer services or share information Their communication interfaces are necessarily open (to allow new clients to access them) – an attacker can send a message to any interface Networks are insecure: For example, message sources can be falsified – messages can be made to look as though they came from Alice when they were actually sent by Mallory Host addresses can be ‘spoofed’ – Mallory can connect to the network with the same address as Alice and receive copies of messages intended for her Limit the lifetime and scope of each secret: When a secret key is first generated we can be confident that it has not been compromised The longer we use it and the more widely it is known, the greater the risk The use of secrets such as passwords and shared secret keys should be time-limited, and sharing should be restricted Algorithms and program code are available to attackers: The bigger and the more widely distributed a secret is, the greater the risk of its disclosure Secret encryption algorithms are totally inadequate for today’s large-scale network environments Best practice is to publish the algorithms used for encryption and authentication, relying only on the secrecy of cryptographic keys This helps to ensure that the algorithms are strong by throwing them open to scrutiny by third parties Attackers may have access to large resources: The cost of computing power is rapidly decreasing We should assume that attackers will have access to the largest and most powerful computers projected in the lifetime of a system, then add a few orders of magnitude to allow for unexpected developments Minimize the trusted base: The portions of a system that are responsible for the implementation of its security, and all the hardware and software components upon which they rely, have to be trusted – this is often referred to as the trusted computing base Any defect or programming error in this trusted base can produce security weaknesses, so we should aim to minimize its size For example, application programs should not be trusted to protect data from their users 844 CHAPTER 19 MOBILE AND UBIQUITOUS COMPUTING trade agreement on the set of functions in an interface against agreement on the types of data that are passed as arguments to those functions While XML (see Section 4.3.3) is sometimes touted as a way of facilitating data interoperation by enabling data to be ‘self-describing’, in fact it merely provides a framework for expressing structure and vocabulary In itself, XML has nothing to contribute to what is a semantic problem Some authors consider the ‘Semantic Web’ [www.w3.org XX] to be the way to achieve interoperability between machines, without human interpretation 19.4 Sensing and context awareness The foregoing sections have concentrated on aspects of the volatility of mobile and ubiquitous systems This section will concentrate on the other chief characterization of those systems: that of being integrated with the physical world Specifically, it will consider architectures for processing data collected from sensors, and context-aware systems that can respond to their (sensed) physical circumstances The sensing of location, an important physical parameter, will be examined in more detail Since users and the devices we are considering are often mobile, and since the physical world presents different opportunities for rich interactions across locations and times, their physical circumstances are often relevant as a determinant of system behaviour The context-aware braking system of a car could adjust its behaviour according to whether the road conditions are icy A personal device could automatically harness resources detected in its environment, such as a large display The Active Badge system provides a historical example: the location of a user – that is, the location of the badge they wore – was used to identify which phone their calls should be routed to [Want et al 1992], in the days before mobile phones The context of an entity (person, place or thing, whether electronic or otherwise) is an aspect of its physical circumstances of relevance to system behaviour The context includes relatively simple values such as the location, time and temperature, the identity of an associated user – e.g., one operating a device – or other users nearby; and the presence and state of an object such as another device, e.g., a display Context can be codified and acted upon through rules, such as ‘If the user is Fred and he is in an IQ Labs meeting room, and if there is a display within m, then show information from the device on the display – unless a non-IQ Labs employee is also present’ Context is also taken to include more complex attributes such as the user’s activity For example, a context-aware phone that has to decide whether to ring requires answers to questions such as ‘Is the user in a cinema watching a film or are they chatting to their friends before the screening?’ 19.4.1 Sensors The determination of a contextual value begins with sensors, which are combinations of hardware and/or software used to measure contextual values Some examples are: Location, velocity and orientation sensors: Satellite navigation (GPS) units for providing global coordinates and velocities; accelerometers to detect movement; magnetometers and gyroscopes to provide orientation data SECTION 19.4 SENSING AND CONTEXT AWARENESS 845 Ambient condition sensors: Thermometers; sensors that measure light intensity; microphones for sound intensity Presence sensors: Sensors that measure physical load, e.g to detect the presence of a person sitting on a chair or walking across a floor; devices that read electronic identifiers on tags brought near to them, such as RFID (Radio Frequency IDentification, a subset of NFC) readers [Want 2004], or infrared readers such as those used to sense active badges; software used to detect key presses on a computer The above categories are meant only as examples of sensors used for particular purposes A given sensor may be put to various purposes For example, the presence of humans could be detected using microphones in a meeting room and an object’s location could be determined by detecting the presence of its active badge in a known place An important aspect of a sensor is its error model All sensors produce values with some degree of error Some sensors, e.g thermometers, can be manufactured so that the errors fall within the bounds of a fairly well known tolerance, and with a known (e.g., Gaussian) distribution Others, such as satellite navigation units, have complicated error modes that depend on their current circumstances First, they may fail to produce a value at all in certain circumstances Satellite navigation units are dependent on the set of satellites currently visible They typically not work at all inside buildings, whose walls attenuate the satellite signals too much for the units to operate Second, the calculation of the unit’s location depends on dynamic factors including satellite positions, the existence of nearby occlusions and ionospheric conditions Even outside buildings, a unit will typically provide different values at different times for the same location, with only a best-effort estimate of the current accuracy Near to buildings or other tall objects that occlude or reflect radio signals, just enough satellites may be visible to produce a reading, but the accuracy may be low and the reading may even be spurious A useful way to state a sensor’s error behaviour is to quote an accuracy that it reaches for a specified proportion of measurements, for example: ‘Within the given area, the satellite navigation unit was found to be accurate to within 10 m for 90% of measurements’ Another approach is to state a confidence value for a particular measurement – a number (usually between and 1) chosen according to uncertainties encountered in deriving the measurement 19.4.2 Sensing architectures Salber et al [1999] identify four functional challenges to be overcome in designing context-aware systems: Integration of idiosyncratic sensors: Some of the sensors needed for context-aware computing are unusual in their construction and programming interfaces Specialized knowledge may be needed to correctly deploy them in the physical scenario of interest (e.g., where should accelerometers be attached to measure the user’s arm gestures?), and there may be system issues such as the availability of drivers for standard operating systems Abstracting from sensor data: Applications require abstractions of contextual attributes, to avoid concern with the peculiarities of individual sensors The problem 846 CHAPTER 19 MOBILE AND UBIQUITOUS COMPUTING is that even sensors that can be put to similar purposes typically provide different raw data For example, a given location may either be sensed as a latitude/longitude pair by a satellite navigation sensor, or sensed as the string ‘Joe’s Café’ read from a nearby infrared source Either, both or neither might be what the application needs to function There needs to be agreement on the meaning of contextual attributes, and software to infer those attributes from raw sensor values Sensor outputs may need to be combined: Reliably sensing a phenomenon may entail combining values from several error-prone sources For example, detecting the presence of a person might require a microphone (to detect voice – but nearby sounds might interfere), floor pressure sensors (to detect human movement – but different users’ patterns are hard to distinguish) and video (to detect human forms – but facial features are hard to distinguish) Combining sensor sources to reduce errors is known as sensor fusion Equally, an application may require output from sensors of different types in order to gather several contextual attributes that it needs to operate For example, a context-aware smart phone that decides whether to present data on a nearby display requires data from different sensor sources, including ones to detect who and which devices are present, and one or more to sense the location Context is dynamic: A context-aware application typically needs to respond to changes in context, and not simply to read a snapshot of it For example, the context-aware smart phone needs to blank its data from the room’s display if a nonemployee enters, or if Fred (the device’s owner) leaves the room Researchers have devised various software architectures to support context-aware applications while dealing with some or all of the above issues We give examples of architectures for situations in which the set of available sensors is more or less known and static, and architectures for determining contextual attributes from volatile collections of sensors (where non-functional requirements such as energy-saving also become prominent) Sensing in the infrastructure • Active badge sensors were originally deployed in the laboratory of Olivetti Research in Cambridge, England, at known, fixed locations in the building One of the original context-aware applications was as an aid for a telephone receptionist If someone called for, say, Roy Want, the receptionist would look for Roy’s room location on the screen, so they could put the call through to an appropriate extension The system determined Roy’s location from information about where the badge he wore was last sensed, and displayed that information to the receptionist Systems for processing active badge data and other contextual data were refined at Olivetti Research Labs and at Xerox PARC Harter and Hopper [1994] describe an entire system for processing location events Schilit et al [1994] also describe a system that can process active badge sensing events, through what they call context-triggered actions For example, the specification: Coffee Kitchen arriving 'play -v 50 /sounds/rooster.au' would cause a sound to be played whenever a badge was sensed arriving at the sensor mounted by the coffee machine in the kitchen SECTION 19.4 SENSING AND CONTEXT AWARENESS 847 Figure 19.5 The IdentityPresence widget class of the Context Toolkit Attributes (accessible by polling) Explanation Location Location the widget is monitoring Identity ID of the last user sensed Timestamp Time of the last arrival Callbacks PersonArrives(location, identity, timestamp) Triggered when a user arrives PersonLeaves(location, identity, timestamp) Triggered when a user leaves The Context Toolkit [Salber et al 1999] is an example of a system architecture for more general context-aware applications than those based around a specific technology such as active badges It was the designers of the Context Toolkit who stated the four challenges for context-aware systems listed above Their architecture follows the model of how graphical user interfaces are constructed from reusable widget libraries, which hide most of the concerns of dealing with the underlying hardware – and much of the interaction management – from the application developer The Context Tzoolkit defines context widgets Those reusable software components present an abstraction of some type of context attribute while hiding the complexity of the actual sensors used For example, Figure 19.5 shows the interface to an IdentityPresence widget It provides contextual attributes to software polling the widget, and it raises callbacks when the contextual information changes (i.e., a user arrives or leaves) As indicated above, the presence information could be derived from any of several combinations of sensors in a given implementation; the abstraction enables the application writer to ignore those details Widgets are constructed from distributed components Generators acquire raw data from sensors such as floor pressure sensors, and provide that data to widgets Widgets use the services of interpreters, which abstract contextual attributes from the generator’s low-level data, deriving higher-level values such as the identity of a person who is present from their distinctive footsteps Finally, widgets called servers provide further levels of abstraction by collecting, storing and interpreting contextual attributes from other widgets For example, a PersonFinder widget for a building could be constructed from the IdentityPresence widgets for each room in the building (Figure 19.6), which in turn could be implemented using footstep interpretation from floor pressure readings or face recognition from video capture The PersonFinder widget encapsulates the complexity of a building for the application writer Looked at in relation to the four challenges that the Context Toolkit’s designers stated, their architecture does accommodate a variety of sensor types; it is geared towards the production of abstract contextual attributes from raw sensor data; and, through polling or callbacks, a context-aware application can learn about changes in its context However, the toolkit goes only a limited way towards a practical solution It does not of itself help users and programmers to integrate idiosyncratic sensors; neither 848 CHAPTER 19 MOBILE AND UBIQUITOUS COMPUTING Figure 19.6 A PersonFinder widget constructed using IdentityPresence widgets PersonFinder Room A Widgets IdentityPresence IdentityPresence Footstep recognition (interpreter) Floor pressure (generators) Video (generator) Room B Face recognition (interpreter) does it solve any of the hard problems inherent in the processes of interpretation and combination for a specific case Wireless sensor networks • We have discussed architectures for applications in which the set of sensors is relatively stable – for example, where the sensors are installed in rooms in a building, often with external power and wired network connections We now turn to cases where the set of sensors forms a volatile system A wireless sensor network consists of a (typically large) number of small, low-cost devices or nodes, each with facilities for sensing, computing and wireless communication [Culler et al 2004] It is a special case of an ad hoc network: the nodes are physically arranged more or less randomly, but they can communicate over multiple wireless hops between their peers An important design goal for these networks is to function without any global control; each node bootstraps itself by discovering its wireless neighbours and communicating via them alone Section 3.5.2 describes ad hoc configurations of 802.11 networks, but lower-power technologies such as ZigBee (IEEE 802.15.4) are more relevant here One reason why nodes communicate not in a single hop to all other nodes but only with nodes located nearby is that wireless communication is costly in terms of power consumption, which increases as the square of radio range The other main reason for restricting the range of individual radios is to reduce network contention Wireless sensor networks are designed to be added to an existing natural or built environment and to function independently of it – i.e., without reliance on infrastructure Given their limited radio and sensing range, the nodes are installed at a sufficient density to make it probable both that multihop communication will be possible between any pair of nodes, and that significant phenomena can be sensed For example, consider devices placed throughout a forest whose job is to monitor for fires and perhaps other environmental conditions, such as the presence of animals These nodes are very much the devices introduced in Section 19.1.1 They each have sensors attached, e.g for temperature, sound and light; they run on batteries; and they communicate with other devices in a peer-to-peer fashion via short-range radio communication The volatility stems from the fact that these devices can fail due to battery exhaustion or accidents such as fires; and their connectivity may change due to SECTION 19.4 SENSING AND CONTEXT AWARENESS 849 node failures (nodes relay packets between other nodes) or environmental conditions affecting radio propagation Another example is where the nodes are attached to vehicles to monitor traffic and road conditions A node that has observed a poor condition can relay information about it via nodes on passing vehicles With sufficient overall connectivity, this system can warn other nearby drivers headed in the direction of the problem Here the volatility arises principally because of the nodes’ movement, which rapidly changes each node’s state of connectivity with other nodes This is an example of a mobile ad hoc network In general, wireless sensor networks are dedicated to an application-specific purpose that amounts to detecting certain alarms – conditions of interest such as fires or poor road conditions At least one more powerful device, a root node, is usually included in the network, for longer-range communication with a conventional system that reacts to the alarms – for example, by calling the emergency services when there is a fire One approach to software architectures for sensor networks is to treat them similarly to conventional networks by separating the network layer from higher layers In particular, it is possible to adapt existing routing algorithms to the graph of nodes as they dynamically discover themselves to be connected by their direct radio links, with each node able to act as a router for communications from other nodes Adaptive routing, which attempts to accommodate the volatility of the network, has been the subject of much study, and Milanovic et al [2004] provide an overview of some techniques However, limiting concern to the network layer raises issues First, adaptive routing algorithms are not necessarily tuned to low energy (and bandwidth) consumption Second, volatility undermines some of the assumptions in traditional layers above the network layer An alternative, first-principles approach to software architectures for wireless sensor networks is driven by two main requirements: energy conservation and continuous operation despite volatility Those two factors lead to three main architectural features: in-network processing, disruption-tolerant networking and data-oriented programming models In-network processing: Not only is wireless communication absolutely costly in energy consumption, but it is relatively expensive compared to processing Pottie and Kaiser [2000] calculated energy consumption and found that a general-purpose processor could execute million instructions for the same amount of energy (3J) used to transmit kbit of data 100 m by radio So, in general, processing is preferable to communication: it is better to spend some processor cycles determining whether communication is (yet) necessary, than to blindly transmit sensed data Indeed, that is why the nodes in sensor networks have a processing capability – otherwise, they could have consisted simply of sensing modules and communication modules that would send sensed values to root nodes for processing The phrase in-network processing refers to processing within the sensor network; that is, on the network nodes The nodes in a sensor network perform tasks such as aggregating or averaging values from nearby nodes so as to examine values for an area rather than a single sensor filtering out data of no interest or repeated data, examining data to detect alarms and switching sensors on or off according to the values being sensed For example, if low-power light sensors indicate the possible presence of animals (due to the casting of shadows), then the nodes near to where the shadows were 850 CHAPTER 19 MOBILE AND UBIQUITOUS COMPUTING cast could switch on their higher-power sensors, such as microphones, to try to detect animal sounds That scheme enables the microphones to be turned off otherwise, to conserve energy Disruption-tolerant networking: The end-to-end argument (Section 2.3.3) has been an important architectural principle for distributed systems However, in volatile systems such as sensor networks, it may be that no end-to-end path exists continuously for long enough to achieve an operation such as the movement of data in bulk across a system The terms disruption tolerant networking and delay tolerant networking are used for protocols to achieve higher-layer transfers across volatile (and typically heterogeneous) networks [www.dtnrg.org] The techniques are intended not only for sensor networks but also other volatile networks, such as interplanetary communication systems needed for space research [www.ipnsig.org] Rather than relying on continuous connectivity between two fixed endpoints, communication becomes opportunistic: data are transferred as and when they can be, and nodes take on successive responsibilities to move data in a store-and-forward fashion until an end-to-end goal such as bulk transport has been attained The unit of transfer between nodes is known as a bundle [Fall 2003], which contains a source’s application data and data describing how to manage and process it both at the endpoint and at intermediate nodes For example, a bundle might be transferred with hop-by-hop reliable transports; once a bundle has been handed over, the recipient node assumes responsibility for its subsequent delivery over the next hop, and so on This procedure does not rely on any continuous route; also, resource-poor nodes are relieved from storing the data as soon as they have transferred it to the next hop To guard against failure, data can be forwarded redundantly to several neighbouring nodes Data-oriented programming models: Turning to interoperation in the application layers, data-oriented techniques including directed diffusion and distributed query processing, described shortly, have been developed for applications of sensor networks These techniques recognize the need for in-network processing by incorporating methods for distributing the processing across the nodes Moreover, the techniques recognize the volatility of sensor networks by eliminating node identities – and any other names for components such as processes or objects associated with a node As we discussed in Section 19.3.2, any program that relies on the continuous existence of a node or a component will not work robustly in a volatile system, since there is a significant chance that communication with that node or component will become impossible In directed diffusion [Heidemann et al 2001], the programmer specifies interests, which are declarations of tasks injected into the system at certain nodes called sinks For example, a node might express an interest in the presence of animals Each interest contains attribute-value pairs, which are the ‘names’ of the nodes that will perform the task Thus nodes are referred to not through their identity but through characteristics required to perform the required task, such as values in a certain range that are being sensed there The runtime system propagates interests from a sink through the network in a process called diffusion (Figure 19.7a) The sink forwards the interest to neighbouring nodes Any node that receives an interest stores a record of it, along with information needed to pass data back to the sink node, before propagating it further in the search for nodes that match the interest A source node is one that matches an interest by virtue of SECTION 19.4 SENSING AND CONTEXT AWARENESS 851 Figure 19.7 Directed diffusion sink sink sink source source (a) Interest propagation source source (b) Gradients set up source source (c) Data delivery characteristics that match the attribute-value pairs specified in the interest – for example, it may be equipped with appropriate sensors There may be several source nodes for a given interest (just as there may be several sinks at which the interest was injected) When the runtime system finds a matching source node, it passes the interest to the application, which turns on its sensors as required and generates the data needed by the sink node The runtime system ferries that data back to the sink along a reverse path made up of nodes that forwarded the interest from the sink Since, in general, no node has a priori knowledge of which other node can act as a source, directed diffusion may involve considerable redundant communication At worst, the entire network may be flooded with an interest However, sometimes the interest concerns only a certain physical region, such as a specific area in a forest If sensor nodes know their locations, then the interest need be propagated only to the target area In principle, nodes could be equipped with satellite navigation receivers for that purpose, although natural coverage such as dense trees may obstruct readings The flow of data back from source to sink is controlled by gradients, which are (direction, value) pairs between nodes that are set up for each particular interest as it diffuses through the network (Figure 19.7b) The direction is that in which the data is to flow, and the value is application-specific but can be used to control the rate of flow For example, the sink might require data about animal sightings only a certain number of times per hour There may be several paths from a given source to a given sink The system can apply various strategies for choosing among them, including using paths redundantly in case of failure, or applying heuristics to find a path of minimum length (Figure 19.7c) The application programmer can also supply software called filters that run on each of the nodes to intercept the flow of matching data passing through the node For example, a filter could suppress duplicate animal-detection alarms that derive from different nodes sensing the same animal (possibly the node between the sources and sink in Figure 19.7c) Another data-oriented approach to programming sensor networks is distributed query processing [Gehrke and Madden 2004] In this case, however, an SQL-like language is used to declare queries that will be executed collectively by the nodes The optimum plan for executing a query is typically processed on the user’s PC or base station outside the network, taking into account any known costs associated with the use 852 CHAPTER 19 MOBILE AND UBIQUITOUS COMPUTING of particular sensor nodes The base station distributes the optimized query to the nodes in the network along dynamically discovered routes, taking into account the communication patterns that processing the query entails, such as sending data to collection points for averaging As with directed diffusion, data can be aggregated in the network to amortize communication costs The results flow back to the base station for further processing 19.4.3 Location sensing Of all the types of sensing used in ubiquitous computing, location sensing has received the most attention Location is an obvious parameter for mobile, context-aware computing It seems natural to make applications and devices behave in a way that depends on where the user is, as in our example of the context-aware phone But location sensing has many other uses, from assisting users in navigating through urban or rural areas to determining network routes by geography [Imielinski and Navas 1999] Location-sensing systems are designed to obtain data about the position of entities, including objects and humans, within some type of region of interest Here we concentrate on entities’ locations, but some technologies also derive values for their orientation and higher-order values such as their velocities An important distinction, especially when it comes to privacy, is whether an object or user determines its own location, or whether something else determines its location The latter case is known as tracking Figure 19.8 (based on a similar figure in Hightower and Borriello [2001]) shows some types of location technologies, and some of their principal characteristics One characteristic is the mechanism used to derive a location That mechanism sometimes imposes limitations on where the technology can be deployed, such as whether the technology works indoors or outdoors, and what installations are required in the local infrastructure The mechanism is also associated with an accuracy, given in Figure 19.8 to an order of magnitude Next, different technologies yield different types of data about an object’s location Finally, technologies differ in what information, if any, is supplied about the entity being located, which is relevant to users’ concerns about privacy Additional technologies are surveyed in Hightower and Borriello The US Global Positioning System (GPS) is the most well-known instance of a satellite navigation system – a system for determining the approximate position of a receiver or unit from satellite signals Other satellite navigation systems are the Russian GLONASS system and the planned European Galileo system GPS, which functions only outdoors because of signal attenuation inside buildings, is used routinely in vehicles and in handheld navigation devices, and increasingly for less conventional applications such as the delivery of location-dependent media to people in urban areas [Hull et al 2004] The receiver’s position is calculated with respect to a subset of 24 satellites that are orbiting the Earth in six planes, satellites per plane Each satellite orbits the Earth about twice per day, broadcasting the current time from an on-board atomic clock and information about its locations over a range of times (as judged by observations from ground stations) The receiver whose location is to be determined calculates its distance from each of several visible satellites using the difference between the time of arrival of the signal and the time it was broadcast – that is, the time encoded in the signal – and an estimate of the speed of radio propagation from the satellite to SECTION 19.4 SENSING AND CONTEXT AWARENESS 853 Figure 19.8 Type Some location-sensing technologies Mechanism Limitations Accuracy Type of location data Privacy GPS Multilateration from satellite radio sources Outdoors only (satellite visibility) 1–10 m Absolute geographic coordinates (latitude, longitude, altitude) Yes Radio beaconing Broadcasts from wireless base stations (cellular, 802.11, Bluetooth) Areas with wireless coverage 10 m–1 km Proximity to known entity (usually semantic) Yes Active Bat Multilateration from radio and ultrasound Ceilingmounted sensors 10 cm Relative (room) coordinates Bat identity disclosed Ultra Wide Band Multilateration from reception of radio pulses Receiver installations 15 cm Relative (room) coordinates Tag identity disclosed Active Badge Infrared sensing Sunlight or fluorescent light room size Proximity to known entity (usually semantic) Badge identity disclosed Automatic identification tag RFID, Near Field Communication, visual tag (e.g barcode) Reader installations cm–10 m Proximity to known entity (usually semantic) Tag identity disclosed Easy Living Vision, triangulation Camera installations Variable Relative (room) coordinates No Earth The receiver then calculates its position using a trigonometric calculation known as multilateration At least three satellites must be visible from the receiver to obtain a position The receiver can calculate only its latitude and longitude if just three satellites are visible; with more satellites visible, altitude can also be calculated Another positioning method that potentially works over a wide area, at least in highly populated regions, is to identify nearby beacons in the form of fixed wireless nodes with a limited transmission range Devices can compare signal strengths as a measure of which beacon is nearest Cellular base stations for mobile phones (also known as cell towers) each have a cell ID; 802.11 access points have a Basic Service Set Identifier (BSSID) Some beacons broadcast identifying information; others are discovered For example, many 802.11 access points broadcast their identifiers, while a Bluetooth device provides its identifier upon discovery by another device Radio beaconing does not determine an entity’s position per se, only its proximity to another entity If the beacon’s position is known, then the target entity’s position is known to within the beacon’s radio range Absolute positioning requires looking up the beaconed identifier in a database of locations Telecommunication providers disclose positioning information using the locations of their cell towers, either directly or via third parties Some companies, such as Google, use vehicles to systematically trawl 854 CHAPTER 19 MOBILE AND UBIQUITOUS COMPUTING Figure 19.9 Locating an active bat within a room Base station sends timing signal to ultrasound receivers and radio signal to bat simultaneously Ultrasound receivers report times of flight of ultrasound pulse Active bat emits ultrasound signal on receipt of radio signal Base station computes distances to ultrasound receivers from times of flight, and thus position of bat areas for 802.11 access points, which they map using GPS positioning A smart phone’s location can be determined to within tens of metres when in range of such a mapped access point (assuming that the access point has not been relocated, which sometimes occurs) Proximity can be a useful property in itself For example, using proximity it is possible to create location-aware applications that are triggered by the return to a previously visited location – a user waiting at a train station could create an alert reminding them to buy a new monthly train ticket when they enter the proximity of the train station (that is, when their device receives the same beaconed identifier) on the first of the month Bluetooth, an alternative radio technology, has the interesting property that some radio beacons – for example, ones integrated with mobile phones – are themselves mobile This can be useful too For example, train commuters could receive data from people they frequently travel with – ‘familiar strangers’ – provided via their mobile phones Turning back to more definite forms of positioning, GPS derives an object’s absolute (that is, global) coordinates outdoors By contrast, the Active Bat system [Harter et al 2002] was designed to determine an object’s or human’s location indoors, in relative coordinates – that is, with respect to the room in which the object or user is located (Figure 19.9) The Active Bat system is accurate to about 10 cm Relatively accurate indoor location information is useful for applications such as detecting which screen a user is nearest to and ‘teleporting’ their PC’s desktop to that screen using the VNC protocol (see ‘Thin client implementations’ in Section 2.3.2) A bat is a device that is attached to the user or object whose location is to be found, and that receives radio signals and emits ultrasound signals The system relies on a grid of ultrasound receivers at known locations in the ceiling, wired to a base station To locate a bat, the base station simultaneously emits a radio signal to the bat containing its identifier, and a wired signal to the ceiling-mounted ultrasound receivers When the bat with the given identifier receives the base station’s signal, it emits a short ultrasound pulse When a receiver in the ceiling receives the base station’s signal, it starts a timer Since the speed of electromagnetic propagation is so much greater than the speed of sound, the emission of the ultrasound pulse and the start of the timer are effectively simultaneous When a ceiling receiver receives the corresponding ultrasound pulse (from the bat), it reads the elapsed time and forwards it to the base station, which uses an estimate of the speed of SECTION 19.4 SENSING AND CONTEXT AWARENESS 855 sound to deduce the receiver’s distance from the bat If the base station receives distances from at least three non-colinear ultrasound receivers, it can compute the bat’s position in 3D space Ultra Wide Band (UWB) is a wireless communication technology for propagating data at high bit rates (100 Mbps or more) over short ranges (up to 10 m) The bits are propagated at very low power but over a very wide frequency spectrum, using thin pulses – on the order of ns in width Given the size and shape of the pulse, it is possible to measure times of flight with great accuracy By arranging receivers in the environment and using multilateration it is possible to determine a UWB tag’s coordinates to an accuracy of about 15cm Unlike the above technologies, UWB signals propagate through walls and other typical objects found in the built environment Its low power consumption is another advantage Some researchers have experimented with the use of existing wireless nodes such as 802.11 wireless access points to go beyond simple beaconing, and to attempt to infer the location of a wireless client by measuring signal strength with respect to several access points In practice, the presence of other entities in the environment that attenuate, reflect or refract the signal means that signal strength is not a simple function of distance from the transmitter One approach to dealing with that issue is fingerprinting, which probabilistically determines locations from signal strength characteristics as measured throughout the space As part of the Place Lab project, Cheng et al [2005] consider some techniques for determining locations from signal strengths, the accuracy that can be obtained and the amount of calibration that is involved The preceding technologies provide data about an object’s physical location: its coordinates in a physical region One advantage of knowing a physical location is that, through databases including geographical information systems (GIS) and world models of built spaces, a single location can be related to many types of information about the object or its relationship to other objects However, considerable effort is required to produce and maintain those databases, which can be subject to high rates of change By contrast, the Active Badge system (Section 19.1) produces an object’s semantic location: the location’s name or description For example, if a badge is sensed by the infrared receiver in room ‘101’, then the location of that badge is determined to be ‘Room 101’ (Unlike with most radio signals, building materials strongly attenuate infrared signals so the badge is unlikely to be outside the room.) That data tells us nothing explicitly about the location in space, but it does provide users with information that relates to their knowledge of the world they live in By contrast, the latitude and longitude of the same place, such as 51° 27.010 N, 002° 37.107 W, is useful for, say, calculating distances to other places; but it is difficult for humans to work with Note that radio beacons – which invert Active Badge technologies by placing the receiver on the target to be located rather than in the infrastructure – can be used to provide either semantic or physical locations Active Badges are a specialized form of automatic identification tags: electronically readable identifiers designed typically for mass industrial applications Automatic identification tags include RFID [Want 2004], Near Field Communication (NFC) tags [www.nfc-forum.org] and glyphs or other visual symbols such as barcodes – especially those designed to be readable at a distance by cameras [de Ipiña et al 2002] These tags are attached to the object whose location is to be determined When they are 856 CHAPTER 19 MOBILE AND UBIQUITOUS COMPUTING read by a reader with a limited range and at a known location, the target object’s location becomes known Finally, computer vision techniques may be used to locate an object such as a human viewed by one or more cameras The Easy Living project [Krumm et al 2000] used vision algorithms on feeds from several cameras A target object can be located if it can be recognized by a camera at a known location With several cameras at known locations, in principle the differences between the object’s appearances in their images can be used to determine the object’s location more acurately More specialized devices combine visible light imaging with infrared range-finding to determine the presence of humans and the placement of their hands and limbs as gestural inputs, for example to games As demonstrated in the Cooltown case study (Section 19.7.2), some of the above location technologies – especially automatic identification tags and infrared beacons – can also be used to provide access to information and services concerning the entity to which they are attached, through the identifiers they make available How the above technologies compare with respect to privacy? The GPS solution provides absolute privacy: at no point in the GPS’s operation is information about the receiving device transmitted elsewhere Radio beaconing can also provide absolute privacy but it depends on how it is used If a device simply listens for beacons and never otherwise communicates with the infrastructure, then it maintains privacy By contrast, the other technologies are tracking technologies Active Bats, UWB, Active Badges and automatic identification methods each yield an identifier to the infrastructure indicating presence in a known location at a known time Even if the associated user does not disclose their identity, it might be possible to infer it Finally, Easy Living’s vision techniques rely on recognizing users in order to locate them, so the user’s identity is much more directly disclosed Architectures for location-sensing • Two of the key characteristics required for location systems are: generality with respect to the types of sensor used for location-sensing, and scalability with respect to the number of objects to be located and the rate of location update events occurring when mobile objects such as people and vehicles change their locations Researchers and developers have produced architectures for location sensing in the small – in individual smart spaces such as rooms, buildings, or natural environments covered by sensor networks – and for highly scalable geographic information systems intended to cover large areas and include the locations of very many objects The location stack [Hightower et al 2002, Graumann et al 2003] is aimed at meeting the requirement for generality It divides location-sensing systems for individual smart spaces into layers The sensor layer contains drivers for extracting raw data from a variety of location sensors The measurements layer then turns that raw data into common measurement types including distance, angle and velocity The fusion layer is the lowest layer available to applications It combines the measurements from different sensors (typically of different types) to infer the location of an object and provide it through a uniform interface Since sensors produce uncertain data, the inferences of the fusion layer are probabilistic Fox et al [2003] survey some of the Bayesian techniques available The arrangements layer deduces relationships between objects, such as whether they are co-located Above those are layers for combining SECTION 19.5 SECURITY AND PRIVACY 857 location data with data from other types of sensors to determine more complex contextual attributes, such as whether a group of people located in a house are all asleep Scalability is a major concern in geographic information systems Spatio-temporal queries such as ‘Who has been in this building in the last 60 days?’, ‘Is someone following me?’ or ‘Which moving objects in this region are most in danger of colliding?’ illustrate the need for scalability The number of objects – in particular, the number of mobile objects – to be located and the number of concurrent queries may be large Moreover, in the last of those example queries, real-time responsiveness is required The obvious approach to making location systems scalable is to divide the region of interest recursively into subregions, using data structures such as quadtrees Such indexing of spatial and temporal databases is an active area of research 19.4.4 Summary and perspective This section has described some of the infrastructures that have been devised for context-aware computing We have concentrated primarily on the ways in which sensors are harnessed to produce the contextual attributes on which applications depend for their behaviour We looked at architectures for relatively static collections of sensors, and architectures for highly volatile sensor networks Finally, we described some technologies for the particularly important case of location sensing, some of which are in widespread use The World Wide Web Consortium’s (W3C) geolocation API [www.w3.org XXIV] includes support for presenting location-specific web content to a user by automatically sensing their location with a mobile device using GPS or proximity of a cell tower or 802.11 access point, as discussed above Through context awareness, we integrate the everyday physical world with computer systems A key problem remaining is that, compared to the subtle understanding that humans have of their physical world, the systems we have described are quite crude Not only are sensors (at least, those cheap enough to deploy widely) inevitably inaccurate, but the final stage of producing semantically rich information accurately from raw sensor data is extremely difficult The world of robotics (which involves actuation, a topic we have ignored, in addition to sensing) has been tackling this difficulty for many years In tightly restricted domains such as domestic vacuum cleaning or industrial production, robots can perform reasonably well But generalization from those domains remains elusive 19.5 Security and privacy Volatile systems raise many new issues for both security and privacy First, users and administrators of volatile systems require security for their data and resources (confidentiality, integrity and availability) However, as we pointed out when describing the model of volatile systems in Section 19.1, trust – the basis for all security – is often lowered in volatile systems, because the principals whose components interact spontaneously may have little, if any, prior knowledge of one another, and may not have a trusted third party in common Second, many users are concerned about their privacy – roughly speaking, their ability to control the accessibility of information about 858 CHAPTER 19 MOBILE AND UBIQUITOUS COMPUTING themselves But privacy is potentially more threatened than ever before due to sensing in the smart spaces users pass through Despite these challenges, measures to ensure people’s security and privacy must be lightweight – partly to preserve the spontaneity of interactions, and partly because of the restricted user interfaces of many devices People will not want, for example, to ‘log in’ to a smart pen before they use it in their host’s office! In this section we outline some of the main security and privacy problems for volatile systems Stajano [2002] gives a more detailed treatment of some of these issues Langheinrich [2001] examines the topic of privacy in ubiquitous computing, starting from its historical and legal context 19.5.1 Background Security and privacy are complicated in volatile systems by hardware-related issues such as resource poverty, and because their spontaneity leads to new types of resource sharing Hardware-related issues • Conventional security protocols tend to make assumptions about devices and connectivity that often not hold in volatile systems First, portable devices such as smart phones and sensor nodes can, in general, be more easily stolen and tampered with than devices such as PCs in locked rooms A security design for volatile systems should not rely on the integrity of any subset of devices that could feasibly be compromised For example, if a smart space spans a large enough physical area, then one way to help protect the system’s overall integrity is to make it necessary for an attacker to visit many locations within it at more or less the same time if their attack is to succeed [Anderson et al 2004] Second, devices in volatile systems sometimes not have sufficient computing resources for asymmetric (public-key) cryptography – even when using elliptic curve cryptography (Section 11.3.2) SPINS [Perrig et al 2002] provides security guarantees for the data that low-power nodes in wireless sensor networks exchange in a potentially hostile environment Their protocols use only symmetric-key cryptography, which, unlike asymmetric-key cryptography, is feasible on such low-power devices However, that begs the question of which nodes in a wireless sensor network should share the same symmetric key At one extreme, if all nodes share the same key, then a successful attack on one node will compromise the entire system At the other extreme, if each node shares a distinct key with every other node, then there may be too many keys for nodes with limited memory to store A compromise position is for nodes to share keys only with their nearest neighbours, and to rely on chains of mutually trusting nodes that encrypt messages hop-by-hop, rather than using end-to-end encryption Third, as always, energy is an issue Not only must security protocols be designed to minimize communication overheads to preserve battery life, but in addition limited energy is the basis for a new type of denial of service attack Stajano and Anderson [1999] describe the ‘sleep deprivation torture attack’ on battery-powered nodes: an attacker can deny service by sending spurious messages to run down devices’ batteries as they waste energy receiving them Martin et al [2004] describe other ‘sleep deprivation’ attacks, including more covertly providing devices with code or data that causes them to waste energy through processing For example, an attacker could provide ... First participant Second participant Participant in three- and four-party protocols Participant in four-party protocols Eavesdropper Malicious attacker A server familiar names for principals and. .. Anderson’s Security Engineering [Anderson 20 08] is also outstanding It is replete with object lessons on the design of secure systems, drawn from real-world situations and system security failures... in the security of systems Unfortunately, these are all too common in today’s systems, and they are not necessarily particularly obscure Cheswick and Bellovin [1994] identify 42 weaknesses that