Computer Systems: Theory, Technology, and Applications

Monographs in Computer Science Editors David Gries Fred B. Schneider This page intentionally left blank Andrew Her...

Author: Andrew J. Herbert | Karen Sparck Jones

273 downloads 1546 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Monographs in Computer Science

Editors David Gries Fred B. Schneider

This page intentionally left blank

Andrew Herbert Karen Spa¨rck Jones Editors

Computer Systems Theory, Technology, and Applications

A Tribute to Roger Needham

With 110 Illustrations

Andrew Herbert Microsoft Research Ltd. Roger Needham Building 7 JJ Thomson Avenue Cambridge CB3 0FB UK

Karen Spa¨rck Jones Computer Laboratory University of Cambridge JJ Thomson Avenue Cambridge CB3 0FD UK

Series Editors: David Gries Department of Computer Science The University of Georgia 415 Boyd Graduate Studies Research Center Athens, GA 30602-7404 USA

Fred B. Schneider Department of Computer Science Cornell University 4115C Upson Hall Ithaca, NY 14853-7501 USA

Library of Congress Cataloging-in-Publication Data Herbert, A.J. (Andrew J.), 1954– Computer systems: theory, technology, and applications/[edited by] Andrew J. Herbert, Karen I.B. Spa¨rck Jones p. cm. — (Monographs in computer science) Includes bibliographical references. ISBN 0-387-20170-X (alk. paper) 1. System design. 2. Computer science. I. Spa¨rck Jones, Karen I.B. II. Needham, R.M. (Roger Michael) III. Title. IV. Series. QA276.9.S88H45 2004 005.1′2—dc21 ISBN 0-387-20170-X

2003066215 Printed on acid-free paper.

 2004 Springer-Verlag New York, Inc. All rights reserved. This work may not be translated or copied in whole or in part without the written permission of the publisher (Springer-Verlag New York, Inc., 175 Fifth Avenue, New York, NY 10010, USA), except for brief excerpts in connection with reviews or scholarly analysis. Use in connection with any form of information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed is forbidden. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. Printed in the United States of America. 9 8 7 6 5 4 3 2 1

(SBA)

SPIN 10944769

Springer-Verlag is part of Springer Science+Business Media springeronline.com

Roger Needham 1935 – 2003


Contents

Preface

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

xi

Roger Needham: 50 + 5 Meeting Programme xiii Contributors xv Introduction: Roger Needham Rick Rashid 1 On Access Control, Data Integration, and Their Languages Martín Abadi 9 Protocol Analysis, Composability and Computation Ross Anderson, Michael Bond 15 Access Control in Distributed Systems Jean Bacon, Ken Moody 21 Implementing Condition Variables with Semaphores Andrew D. Birrell 29 Clumps, Clusters and Classification Christopher M. Bishop 39 How to Implement Unnecessary Mutexes Mike Burrows 51 Bioware Languages Luca Cardelli 59 The Economics of Open Systems David D. Clark 67 From Universe to Global Internet Jon Crowcroft 73 Needham-Schroeder Goes to Court Dorothy E. Denning 77 The Design of Reliable Operating Systems Peter Denning 79 An Historical Connection between Time-Sharing and Virtual Circuits Sandy Fraser 85 On Cross-Platform Security Li Gong 89 Distributed Computing Economics Jim Gray 93 The Titan Influence David Hartley 103 Middleware? Muddleware? Andrew Herbert 109 Grand Challenges for Computing Research

viii

18 19 20 21 22 23

24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

Contents

Tony Hoare Sentient Computing Andy Hopper Cyber Security in Open Systems Anita Jones Software Components: Only the Giants Survive Butler W. Lampson Security Protocols: Who Knows What Exactly? Peter Landrock Volume Rendering by Ray-Casting in Shear-Image Order Hugh C. Lauer, Yin Wu, Vishal Bhatia, Larry Seiler A Conceptual Authorization Model for Web Services Paul J. Leach, Chris Kaler, Blair Dillaway, Praerit Garg, Brian LaMacchia, Butler Lampson, John Manferdelli, Rick Rashid, John Shewchuk, Dan Simon, Richard Ward The Trouble with Standards E. Stewart Lee Novelty in the Nemesis Operating System Ian Leslie A Technology Transfer Retrospective Roy Levin An Optical LAN Derek McAuley What’s in a Name? Robin Milner The Cryptographic Role of the Cleaning Lady Bob Morris Real Time in a Real Operating System Sape J. Mullender, Pierre G. Jansen Zen and the Art of Research Management John Naughton, Robert W. Taylor The Descent of BAN Lawrence C. Paulson Brief Encounters Brian Randell Retrieval System Models: What’s New? Stephen Robertson, Karen Spärck Jones Slammer: An Urgent Wake-Up Call Jerome H. Saltzer Caching Trust Rather Than Content M. Satyanarayanan Least Privilege and More Fred B. Schneider Using Sharing to Simplify System Management Michael D. Schroeder

117 125 133 137 147 153

165 173 177 185 195 205 211 213 223 225 229 237 243 249 253 259

Contents

39 40 41 42 43 44 45 46

An RSA-Related Number-Theoretic Surprise Gustavus J. Simmons Application-Private Networks Jonathan M. Smith Using the CORAL System to Discover Attacks on Security Protocols Graham Steel, Alan Bundy, Ewen Denney On the Role of Binding and Rate Adaptation in Packet Networks David Tennenhouse Technologies for Portable Computing Chuck Thacker Multiple Alternative Voting David Wheeler The Semiotics of Umbrellas John Wilkes Computers for Specialized Application Areas Maurice Wilkes Computer Security? Roger Needham Roger Needham: Publications Karen Spärck Jones

ix

269 273 279 287 295 305 311 317 319 327


Preface

Roger learnt that he was seriously ill late in December 2002. When he heard this, Rick Rashid, Microsoft Senior Vice-President for Research, suggested that there should be some occasion to mark Roger’s contribution to the field, and an associated publication. In response, we proposed a one-day meeting with both technical talks and a more personal session about Roger, with the presentation of a volume of papers from Roger’s many technical colleagues as the key element. There was not much time to prepare the volume. So we asked for short papers on any technical topic of each contributor’s choosing likely to be of interest to Roger. The papers could be on an area of current research, a conjecture about the future, or an historical reflection. They had to be delivered in four weeks. We much appreciated the rapid and enthusiastic responses to our invitation, and were delighted with the range of topics covered and their technical interest. We were also grateful, as each editor reviewed all the papers, for the positive spirit with which our comments and suggestions were received. The meeting itself, ‘Roger Needham: 50 and 5,’ marking Roger’s fifty years in Cambridge and five at Microsoft Research, took place on February 17th, 2003. The programme is given, for reference, following this Preface. The entire proceedings were recorded, publicly available at: http://www.research.microsoft.com/needhambook We would like to thank all those who wrote for the volume, and those who spoke at the meeting. We know that Roger was very touched by how many came to the meeting, some from far away, by how many wrote for the volume and in doing so responded to his interests, by the references to his work in the technical talks, and by the accounts of his roles and contributions in the presentation session. At the end of the meeting he said: The first thing to say is thank you very much—which is sort of obvious. The next thing I want to say is one or two words about what I’ve done and what my subject is. In many sorts of engineering the theoretical background is obvious: it’s continuous mathematics which comes from the 18th century. In computing there is a theoretical background and it’s not obvious but it had to be invented, and people in the theoretical part of our subject have devoted themselves to inventing it—which is fine because you can’t expect it to happen by itself and you can’t go and build computer systems with any complexity at all without some formalised understanding to fall back on.

xii

Preface It is an odd thing that in my career I have contributed one or two bits to that, but that’s basically not what I’m about. I have the greatest respect for the people who build the theoretical underpinnings of our subject, and I wish them every success because it will enable the people who want to get on and make things to do it better and to do it more quickly and to do it with less mistakes—and all of this is good: but at the end of the day I am a engineer—

and so saying, he put on his engineer’s hard hat. He died less than two weeks later, on March 1st. Roger’s last major talk was his Clifford Paterson Lecture ‘Computer security?’ at The Royal Society in November 2002. We have included its text, which is also posthumously published in the Society’s Philosophical Transactions, as the last paper in the volume, along with a complete list of Roger’s publications. We have used the classic Needham-Schroeder authentication protocol as the cover design. The papers in this volume are as they originally appeared for the meeting, apart from some minor corrections and some small modifications, necessary in the circumstances, to specific references to Roger. These papers address issues over the whole area of computer systems, from hardware through operating systems and middleware to applications, with their languages and their implementations, and from devices to global networks; also from many points of view, from designers to users, with lessons from the past or concerns for the future. Collectively, they illustrate what it means to be a computer system.

Acknowledgements We are very grateful to Microsoft for supporting the celebration meeting itself, producing the volume in its original form, and for further supporting the preparation of the volume for formal publication. We are also grateful to Professor Fred Schneider for facilitating the Springer publication and to Tammy Monteith for her work on formatting the material.

Andrew Herbert, Karen Spärck Jones

Roger Needham: 50 + 5 Meeting Programme Title

Presenter

Introduction

Andrew Herbert, Microsoft Research

Time 11 am

TECHNICAL TALKS 11.05 am 11.30 am 12 noon 12.30 pm 1.30 pm 2 pm 2.30 pm 3.00 pm 3.30 pm

Location Aware Computing

Andy Hopper, Cambridge University How Software Components Grew Up and Butler Lampson, Conquered the World Microsoft Research Thoughts on Network Protocol Engineering Jonathan Smith, University of Pennsylvania Lunch Online Science: Putting All Science Data Online and Putting Analysis Tools Online. Logics and Languages for Access Control Protocol Analysis, Composability and Computation Coffee Information and Classification Clumps, Clusters and Classification

Jim Gray, Microsoft Research Martin Abadi, UCSC Ross Anderson, Cambridge University Karen Spärck Jones, Cambridge University Christopher Bishop, Microsoft Research

IN HONOUR OF ROGER NEEDHAM 4.10 pm

Early Days

4.20 pm

Head of Department, Computer Laboratory

4.30 pm

PARC/DEC-SRC Activities

4.40 pm

Pro Vice-Chancellor, Public Service

4.45 pm

Microsoft Managing Director

4.55 pm

Presentation

5 pm

Reception

Maurice Wilkes, Cambridge University Ian Leslie, Cambridge University Mike Schroeder, Microsoft Research Alec Broers, Cambridge University Rick Rashid, Microsoft Research Andrew Herbert Microsoft Research


Contributors

Martín Abadi

Ewen Denney

University of California, Santa Cruz, CA, USA

QSS Group Inc, NASA, Moffet Field, CA, USA

Ross Anderson

Dorothy Denning

University of Cambridge, England

Naval Postgraduate School, Monterey, CA, USA

Jean Bacon University of Cambridge, England

Peter Denning

Andrew Birrell

Naval Postgraduate School, Monterey, CA, USA

Microsoft Research—Silicon Valley, CA, USA

Sandy Fraser Bernardsville, NJ, USA

Christopher Bishop Microsoft Research Ltd, Cambridge, England

Li Gong Sun Microsystems, Santa Clara, CA, USA

Michael Bond University of Cambridge, England

Jim Gray

Alan Bundy

Microsoft Research, San Francisco, CA, USA

University of Edinburgh, Scotland

David Hartley Mike Burrows

Cambridge, England

Google Research, Mountain View, CA, USA

Andrew Herbert

Luca Cardelli

Microsoft Research Ltd, Cambridge, England


Tony Hoare

David Clark


MIT, Cambridge, MA, USA

Andy Hopper John Crowcroft University of Cambridge, England


xvi

Contributors

Pierre Jansen

Sape Mullender

University of Twente, Enschede, The Netherlands

Lucent Technologies, Murray Hill, NJ, USA

Anita Jones

John Naughton

University of Virginia, Charlottesville, VA, USA

Open University, Milton Keynes, England

Butler Lampson

Lawrence Paulson

Microsoft Research, Redmond, WA, USA


Brian Randell Peter Landrock,

University of Newcastle, England

Århus University, Denmark

Rick Rashid, Hugh Lauer TeraRecon, Inc., Concord, MA, USA

Microsoft Research, Redmond, WA, USA

Paul Leach

Stephen Robertson

Microsoft Corporation, Redmond, WA, USA


Stewart Lee

Jerome Saltzer

Orillia, Ontario, Canada

MIT, Cambridge, MA, USA

Ian Leslie

Mahadev Satyanarayanan


Carnegie Mellon University, Pittsburgh, PA, USA

Roy Levin Microsoft Research—Silicon Valley, CA, USA

Fred Schneider

Derek McAuley

Michael Schroeder

Intel Research, Cambridge, England

Microsoft Research—Silicon Valley, CA, USA

Cornell University, Ithaca, NY, USA

Robin Milner University of Cambridge, England

Gustavus Simmons Sandia Park, NM, USA

Ken Moody University of Cambridge, England

Jonathan Smith

Bob Morris

University of Pennsylvania, Philadelphia, PA, USA

Dartmouth College, Hanover, NH, USA

Karen Spärck Jones University of Cambridge, England

Contributors

Graham Steel

David Wheeler

University of Edinburgh, Scotland


Robert Taylor

John Wilkes

Woodside, California, USA

HP Labs, Palo Alto, CA, USA

David Tennenhouse

Maurice Wilkes

Intel Research, Santa Clara, CA, USA


Chuck Thacker Microsoft Corporation, Redmond, WA, USA

xvii


Introduction: Roger Needham1

Rick Rashid Senior Vice President, Microsoft Research

I first encountered Roger Needham almost 20 years ago while lecturing in an advanced course on distributed systems being held in Glasgow during the summer of 1983. I must admit that I felt just a bit out of place lecturing alongside the likes of Gerald Le Lann, Jim Mitchell and Roger Needham. Roger had become head of Cambridge University’s fabled Computer Laboratory just three years earlier, about the same time I had received my Ph.D. When I heard Roger lecture for the first time, I was taken aback by his remarkable and very unusual speaking style. I’ve since seen it described in the press as “deliberate and thoughtful,” and it is all of that. Listening to a lecture in computer science can sometimes make you feel as though you are chasing after the words trying to piece together the speaker’s meaning. When Roger spoke I found myself hanging on each word, wondering with great anticipation what would come next. The wait was usually worthwhile. That summer in 1983 I discovered to my delight Roger’s keen insight, dry wit and ability to turn the English language into his personal plaything: An improvement is something your program will not work with and a bug fix is something it will not work without.

Looking back, I still find it hard to believe that 20 years later I would be running a large research organization for Microsoft and would have the privilege of working with Roger on a daily basis as Managing Director of our Cambridge research laboratory. It has been quite a journey.

Early career I’ve heard the story told that while studying for his Ph.D., Roger lived in a caravan with his wife Karen Spärck Jones, with whom he also collaborated on sev1

This text is as written before Roger’s death, except for changes in the last paragraph.

2

Rashid

eral papers. The reason for their unorthodox living arrangements was that while completing his Ph.D., Roger and Karen also undertook the building of their own house. Despite this rather strenuous side occupation, Roger completed his Ph.D., at Cambridge in 1961. This was on automatic classification and information retrieval, exciting, new and interdisciplinary areas. At the time, Roger was working with the Cambridge Language Research Unit, which was investigating machine translation, automated retrieval, and the like. He joined the University’s Mathematical Laboratory—what is now known as the Computer Laboratory—in 1962, as a Senior Assistant in Research. Although his Ph.D. was on an applications topic, Roger’s career has been that of a classic—almost prototypical—“systems” computer scientist. It is hard to pin him down to a single area. Roger has made significant contributions to areas such as operating systems, networking, distributed systems, computer security and multimedia. In an interview for SIGSoft’s Software Engineering Notes published in January 2001, Roger is quoted as saying: I regard myself as a systems person, not an OS person, nor a communications systems person. I think all three systems require the same kind of skills.

During his career Roger has had a knack for apparently being at the right place at the right time, working with the right collaborators and hitting on the right idea. Roger is fond of saying, Serendipity is looking for a needle in a haystack and finding the farmer’s daughter.

The reality is that his consistent contributions have had nothing to do with serendipity but rather his personal talents and ability to draw to himself talented people and find ways to inspire and motivate them. The first major system Roger worked on following his Ph.D. was TITAN. The Laboratory, under Maurice Wilkes, was providing the software for hardware built by Ferranti (subsequently ICT/ICL). TITAN was the earliest computer system to employ cache memory, and its operating system was the first multi-access system written outside the US to go into public use. Roger first worked with David Wheeler on design automation, and then became involved in building the operating system. One of Roger’s enduring innovations was the use of a one-way function to protect its password file—something virtually every modern computer system does today. The TITAN file system also introduced the notion of full backup and restore and the ability to do incremental backups. Computing in the 1960s and early 1970s was a “full contact sport.” In keeping with his “systems” image, Roger was not above doing anything that might be required to keep his operating system running. In addition to developing TITAN’s software, he enjoys telling the story of the miserable day he sat in an air conditioning unit pouring water from a bucket over a pile of bricks to cool the system and keep it running for users. As a member of staff, Roger also began to teach, initially for the Diploma and later, when Cambridge accepted Computer Science as a degree subject, to

Introduction

3

undergraduates; and he began to take Ph.D. students, now to be met round the world.

CAP, Rings and the Cambridge Model Distributed System Building on lessons learned from TITAN, in the late 1960s Roger began to concentrate on protection—providing fine-grained access control to resources between users, between users and the operating system, and between operating system modules. From the early 1970s he worked with Maurice Wilkes and David Wheeler on the design and construction of the CAP computer, an experimental machine with memory protection based on capabilities implemented in hardware. Once the machine was running in 1975, Roger then led the development of the machine’s operating system and was responsible for many innovations in computer security. The CAP project received a British Computer Society Technical Award in 1977. As the Internet moves toward adoption of a common web services infrastructure, there is renewed interest in capability based access control today. Working with Maurice Wilkes, David Wheeler, Andy Hopper and others, Roger was also involved in the construction of the Cambridge Ring (1974) and its successor the Cambridge Fast Ring (1980). The 10-megabit-per-second Cambridge Ring put the Computer Laboratory at the forefront of high-speed localarea networking and distributed computing research. The Cambridge Fast Ring ran at 100 megabits per second—still the typical speed of local computer networks more than 20 years later—and helped to inspire the creation of the ATM switching networks in use today. The software developed to run on top of the Cambridge Ring was no less remarkable than the hardware. The Cambridge Model Distributed System on which Roger worked with Andrew Herbert and others was an innovative distributed software environment exploiting the Ring. It included computing components such as a Processor Bank, File Server, Authentication Server, Boot Server, etc., and was an early model for what we would today call “thin client computing.” This line of work on distributed systems was taken further in the 1980s in work with Ian Leslie, David Tennenhouse and others on the Universe and Unison projects, where independent Cambridge Rings that sat at several UK sites were interconnected by satellite (Universe) and high-speed point-to-point links (Unison) to demonstrate wide-area distributed computing. Both rings were used to do real-time voice and video applications (the Cambridge “Island” project)— another “first.” There were several commercial and academic deployments of Cambridge Rings spun out from the Computer Laboratory. It is believed that a derivative of

4

Rashid

the Cambridge Ring still runs part of the railway signalling system at London’s Liverpool Street Station!

Head of Department, Computer Laboratory Roger had been promoted to Reader in Computer Systems in 1973, and was made Professor in 1981. When Maurice Wilkes retired in 1980, Roger became Head of Department. In addition to his personal scientific achievements, Roger oversaw the growth and maturation of Cambridge University’s Computer Laboratory during an important part of its history. When he took over as Head of Department, the Laboratory had a teaching and research staff of 10 and just over 40 Ph.D. students. Ten years later, in 1990, the teaching and research staff had grown to 27, and the number of Ph.D. students had more than doubled. Roger is quoted as referring to this as the Laboratory’s “halcyon days”—an expanding Laboratory and no external interference.

Though the Laboratory’s strength was in systems, and Roger himself was a “systems” scientist, he encouraged new areas to develop, for example, formal methods, and language and information processing. One topic of research Roger particularly promoted at Cambridge was the intersection of multimedia systems and networking. As a result, Cambridge became one of the first research laboratories in the world where teleconferencing and video mail became regular tools for research. Roger continued in the 1980s and 90s to be interested in all aspects of computer systems, but was especially concerned with security. He participated in every one of the ACM Symposia on Operating Systems Principles, and is believed to be the only person to have achieved a 100% attendance record. With Ross Anderson and others he significantly developed and expanded Cambridge research into computer security. He took an active role in creating a security programme at the Newton Institute and hosting an annual Security Protocols Workshop, which he continues to do from Microsoft. He has recently combined his intellectual and (left wing) political interests as a Trustee of the Foundation for Information Policy Research. He has also emphasised, in a related spirit, in his 2002 Saul Gorn Lecture at the University of Pennsylvania and Clifford Paterson Lecture at the Royal Society, that doing system security properly is as much about people as about machines. Referring to Roger’s impact on the Computer Laboratory on the occasion of his Honorary Doctorate from the University of Twente in 1996, Sape Mullender wrote: Needham works as a catalyst. When he is around, systems research gets more focus and more vision. He brings out the best in the people around him. This helps to explain why, for as long as I can remember, the Cambridge Univer-

Introduction

5

sity Computer Laboratory has been among the best systems research laboratories in the world. This is recognized even by Americans, although their national pride doesn’t always allow them to admit that MIT, Stanford, Berkeley, Cornell, and the rest of them, have something to learn abroad, in Cambridge.

Public service Roger began his public service career in the 1960s as a member of the Science Research Council’s Computing Science Committee. His public service activities ramified in the 80s and 90s, extending into all kinds of government and other boards and committees. He has said he found some of them fun—the Alvey Committee, for example, had the opportunity to drive a large national computing research programme; some were interesting, like the Research Councils’ Individual Merit Promotion Panel; and some were keeping a particular show on the road. He has felt the obligation to do these things; he has also enjoyed learning and deploying the skills required to do them effectively. His most recent challenge has been chairing a Royal Society Working Party on intellectual property. Roger was able to exploit these skills, and what he had learnt about the University while Head of Department, as Pro Vice-Chancellor from 1996–1998, with a remit on the research side of the University’s operations. This had all kinds of interesting side-effects, like chairing Electors to Chairs across the University and so getting snapshots of what’s hot in pharmacology, or economic history, or Spanish. The list of awards and honors Roger has received for both his personal achievements and his contributions to Cambridge and to the field is impressive, including being named Fellow of the British Computer Society, Fellow of the Royal Society, Fellow of the Royal Academy of Engineering and Fellow of the ACM. Roger was also awarded the CBE (Commander of the Order of the British Empire) for his services to Computer Science in 2001.

Working with industry One constant of Roger’s career has been his consistent connection to industrial research and development. He was a Director of Cambridge Consultants in the 1960s, and for ten years on the Board of Computer Technology Ltd. He was a consultant to Xerox PARC from 1977 to 1984 and to Digital’s System Research Center from 1984 to 1997. From 1995 to 1997 he was a member of the international advisory board for Hitachi’s Advanced Research Laboratory, and on the Board of UKERNA from its inception until 1998. Spin-offs from the Computer Laboratory had begun in the 1970s, contributing to the “Cambridge Phenomenon.” When Roger was Head of Department, he

6

Rashid

fostered these connections, welcoming the idea of a Laboratory Supporters Club and becoming one of the “Godfathers” for Cambridge entrepreneurs. Some of Roger’s most famous papers were conceived during consulting trips and sabbaticals working at industrial research laboratories. The secure authentication system he described in his 1978 paper with Mike Schroeder of Xerox PARC became the basis for systems such as Kerberos—still in use today—and represented a turning point in distributed system security research. Working with Digital Equipment’s Mike Burrows and Martin Abadi, he created the first formalism for the investigation of security protocols to come into wide use (also called the BAN logic, named for its authors). Roger also made contributions to Xerox’s Grapevine project and Digital’s AutoNet project. Roger valued his longstanding connections with these company research centres. He was also able to observe the business of running a research centre— how, and also how not, to—at first hand. In 1995 Roger was asked in an interview how he viewed the relationship between academic work and industrial work in computer science: If there wasn’t an industry concerned with making and using computers the subject wouldn’t exist. It’s not like physics—physics was made by God, but computer science was made by man. It’s there because the industry’s there.

I didn’t realize it at the time, but I would soon become the beneficiary of Roger’s positive attitude toward working with industry. By the mid 90s, too, Roger was finding university life, squeezed between a rampant audit culture and a lack of money, less and less satisfying. Doing something new without either of these features, and with positive advantages of its own, looked very attractive.

Microsoft Research, Cambridge My personal history intersected again with Roger’s almost 14 years after my first meeting with him in 1983. In 1991 I left Carnegie Mellon University, where I had been teaching for 12 years, and joined Microsoft to start its basic research laboratory: Microsoft Research. From the beginning, Nathan Myhrvold, who had hired me as the first lab director, had contemplated creating a laboratory in Europe to complement the one we were building in the United States. For the first 5 years of Microsoft Research’s growth our Redmond facility was small enough that our first priority was to build it up to critical mass. By 1996 we had grown to over 100 researchers, and it was time to consider expanding outside the US. It was in the fall of 1996 as we were considering European expansion that we learned through the grapevine that Roger Needham was willing to consider taking the position of director of a new lab. When I first heard the news I was tre-

Introduction

7

mendously excited. I couldn’t imagine a better person to anchor this new venture. In December, Nathan Myhrvold, Chuck Thacker, Roger Needham and I all met for a day in a hotel near the San Francisco airport to talk about starting the lab, and by the end of the meeting it was clear we were moving forward. By April of 1997 the lab was announced with much fanfare, and in October of 1997 Microsoft Research Cambridge officially opened with Roger Needham as its Managing Director. In its first temporary space in the middle of Cambridge, the Microsoft lab was close to the Computer Laboratory. Their two new buildings in west Cambridge are also close together, striking additions to the growing West Cambridge campus, and with their people interacting as Roger wanted. In a 1999 interview for the book Inside Out—Microsoft—in Our Own Words, Roger talked about the new lab he had started: I had a complete restart of my career at age 62, when I was asked to open MSR at Cambridge. I asked Rick what he wanted me to do. He said, “Hire the best people and help them to do what they are good at.” Nathan Myhrvold added, “If every project you start succeeds, you have failed.” One of the most important rules of this research game is that unless you can get some of the best people in the field, you should not bother. I spent 35 years at Cambridge surrounded by brilliant people, and I rarely had sufficient money to hire them. That is why I enjoy this job so much.

Just as he was able to build the strength of the Computer Laboratory during the 1980s and 1990s, Roger did a stellar job hiring “some of the best people in the field,” and in so doing turning Microsoft Research Cambridge into one of the premier institutions in Europe and a strong engine for innovation within Microsoft. Technology from Microsoft Research Cambridge is now embedded in many of Microsoft’s key products, including Visual Studio, Office and Windows. Coming full circle, one of the earliest Cambridge technologies incorporated into Microsoft’s products was an information retrieval engine—the field in which Roger received his Ph.D. nearly 40 years earlier.

In celebration of Roger Needham The papers in this volume were written to celebrate Roger’s 50 years at Cambridge and 5 years at Microsoft and the tremendous impact he had on so many people in our field. In them you will find a variety of work contributed by some of the top computer scientists in the world—all of whom had worked with Roger or been touched or influenced by Roger’s work. These papers were a labor of love and friendship and deep admiration. Enjoy


1 On Access Control, Data Integration, and Their Languages

Martín Abadi This paper considers the goals and features of recent languages for access control in distributed systems. In particular, it relates those languages to data integration.

Languages for access control Access control is central to security, and in computer systems it appears in many guises and in many places. Applications, virtual machines, operating systems, and firewalls often have their own access-control machinery, with their own idiosyncrasies, bugs, and loopholes. Physical protection, at the level of doors or wires, is another form of access control. Over the years, there have been many small and large efforts to unify models and mechanisms for access control. Beyond any tiny intellectual pleasure that such unifications might induce, these may conceivably contribute to actual security. For example, when there is a good match between the permissions in applications and those in the underlying platforms, access control mechanisms may have clearer designs, simpler implementations, and easier configurations. The benefits are, however, far from automaticʊthe result is sometimes more problematic than the sum of the partsʊand there probably will always be cases in which access control resorts to ad hoc programs and scripts. Those efforts have sometimes produced general languages for access control (e.g., [2–5, 7, 10, 11]). The languages are flexible enough for programming a wide variety of access control policies (for example, in file systems and for digital rights management). They are targeted at distributed systems in which cryptography figures prominently. They serve for expressing the assertions contained in cryptographic credentials, such as the association of a principal with a public key, the membership of a principal in a group, or the right of a principal to perform a certain operation at a specified time. They also serve for combining credentials from many sources with policies, and thus for making authorization

10

Abadi

decisions. More broadly, the languages sometimes aim to support trust management tasks. Several of the most recent language designs rely on concepts and techniques from logic, specifically from logic programming: Li et al.’s D1LP and RT [10, 11], Jim’s SD3 [7], and DeTreville’s Binder [4]. These are explicitly research projects. Languages with practical aims such as XrML 2.0 include some closely related ideas, though typically with less generality and simpler logic. This note will focus on Binder. One might question whether the use of these sophisticated languages would reduce the number of ways in which access control can be broken or circumvented. Policies in these languages might be difficult to write and to understandʊbut perhaps no worse than policies embodied in Perl scripts and configuration files. There seem to be no hard data on this topic.

A look at Binder Binder is a good representative of this line of work. It shares many of the goals of other languages and several of their features. It has a clean design, based directly on that of logic-programming languages. Basically, a Binder program is a set of Prolog-style logical rules. Unlike Prolog, Binder does not include function symbols; in this respect, Binder is close to the Prolog fragment Datalog. Also, unlike Prolog, Binder has a notion of context and a distinguished relation says. For instance, in Binder we can write: may-access(p,o,Rd) :- Bob says may-access(p,o,Rd) may-access(p,o,Rd) :- good(p)

These rules can be read as expressing that any principal p may access any object o in read mode (Rd) if Bob says that p may do so or if p is good. Here only :- and says have built-in meanings. The other constructs have to be defined or axiomatized. As in Prolog, :- stands for reverse implication (“if”). As in previous logical treatments of access control, says serves to represent the statements of principals and their consequences [1]. Thus, Bob says may-access(Alice,Foo.txt,Rd)

holds if there is a statement from Bob that contains a representation of the formula may-access(Alice,Foo.txt,Rd)

More delicately, Bob says may-access(Alice,Foo.txt,Rd)

On Access Control

11

also holds if there is a statement from Bob that contains a representation of the formula may-access(Alice,Foo.txt,RdWr)

and another one that contains a representation of the rule may-access(p,o,Rd) :- may-access(p,o,RdWr)

The author of an access control policy need not be concerned with the details of how formulas are associated with piles of bits and network protocols. In particular, says abstracts from the details of authentication. When C says S, C may send S on a local channel via a trusted operating system within a computer, on a physically secure channel in a machine room, on a channel secured with shared-key cryptography, or in a certificate with a public-key digital signature. Each formula is relative to a context. In our example, Bob is a context (a source of statements). Another context is implicit: the local context in which the formula applies. For example, may-access(p,o,Rd) :- Bob says may-access(p,o,Rd)

is to be interpreted in the implicit local context, and Bob is the name for another context from which the local context imports statements. This import relation might be construed as a form of trust. There is no requirement that predicates mean the same in all contexts. For example, Bob might not even know about the predicate may-access, and might assert peut-lire(Alice,Foo.txt)

instead of may-access(Alice,Foo.txt,Rd)

In that situation, one may adopt the rule: may-access(p,o,Rd) :- Bob says peut-lire(p,o)

On the other hand, Binder does not provide much built-in support for local name spaces. A closer look reveals that the names of contexts have global meanings. In particular, if Bob exports the rule may-access(p,o,Rd) :Charlie says may-access(p,o,RdWr)

the local context will obtain Bob says may-access(p,o,Rd) :Charlie says may-access(p,o,RdWr)

without any provision for the possibility that Charlie might not be the same locally and for Bob. Other systems, such as SDSI/SPKI [5], include more elaborate naming mechanisms.

12

Abadi

Distributed access control as data integration In the database field, a classic problem is how to integrate multiple sources of data. The basic problem set-up is that there is a collection of databases, each defining some relations, and one wants to do operations (in particular queries) on all of them. The query language may be some variant of Prolog, or of its fragment Datalog. Modern versions of the problem address the case where some or all of the sources of data provide semi-structured objectsʊon the Web in XML, for instance. The languages vary accordingly. Each database may expose a different interface and export its data in a different format. In systems such as Tsimmis [6, 12], wrappers translate data from each source into a common model. Mediators then give integrated views of data from multiple (wrapped) sources. For instance, the following is a mediator, written in the language MSL (Mediator Specification Language) of Tsimmis: @med : q, then p = ½(S + √(S2 – 4n)) and q = ½(S – √(S2 – 4n)) where S is defined by S = n – ĳ(n) + 1. Ȝ(n) = [(p –1) , (q – 1)] always divides ĳ(n) = (p – 1)(q – 1), but the quotient r = ĳ(n)/Ȝ(n) can be as small as 2 or as large as Int[√(n/2)]. In fact, for appropriate choices of the primes p and q, r can be forced to assume any even integer value in this range. Consider a special case in which the extreme values of r are realized. Let p, q1, and q2 be three primes of the form: p = 2m + 1, q1 = 4m + 1 and q2 = 4m – 1. For a prime triple of this form: n1 = 8m2 + 6m + 1, n2 = 8m2 + 2m – 1, ĳ(n1) = 8m2 and ĳ(n2) = 8m2 – 4m, so that the two pairs of values are asymptotically the same size. ĳ(n2)/ĳ(n1) = 1 – 1/2m and n2/n1 = 1 – 1/(2m + ½), while r2 = ĳ(n2) / Ȝ(n2) = 2 and r1 = ĳ(n1) / Ȝ(n1) = 2m. For example, let the prime triple be 331, 661, and 659, then Ȝ(n1) = 660, while Ȝ(n2) = 108,570. The problem is to compute the factors of n, one of which is common to both n1 and n2 and the other pair of which differ only by 2, using values of Ȝ(n) that differ by a factor of m – ½. Unlike the case for ĳ(n), no simple algebraic formula is known to do this.

Observation

1

Given three integers 1 < a < b < c, where a | b and a ł c, define k to be the least integer satisfying ka > c – b. Then b/a is one of the k integers in the interval ((c/a) – k, (c/a)).

Theorem For any RSA modulus, ĳ(n)/Ȝ(n) is the unique even integer in the interval

(n/Ȝ(n – 2, n/Ȝ(n))

1

This is a generalization of a special case first observed by Peter Landrock.

An RSA-Related Number-Theoretic Surprise

271

Proof We show that for an RSA modulus Ȝ(n) = a, ĳ(n) = b, n = c satisfy the conditions of the observation and that k = 2 in this case. Since [x,y]xy for all x and y, the first condition is trivially satisfied. If Ȝ(n) = [(p – 1), (q – 1)], with p > q, divides n = pq, then p – 1 must be q and q – 1 must be 1, i.e., p = 3 and q = 2. Since this is not a possible RSA modulus pair of primes, Ȝ(n) ł n for any RSA modulus and the second condition of the observation is satisfied. To show that k = 2, first note that for the example given above, Ȝ(n1) = 4m < 6m + 1 = n – ĳ(n1), so that k > 1. We next show that for all n = pq, 2 Ȝ(n) > n – ĳ(n) 2[(p – 1), (q – 1)] > n – ĳ(n) = n – n + p + q – 1 [(p – 1), (q – 1)] > ½((p – 1) + (q – 1)) + ½ But for all x > y, [x,y] ½(x + y) + ½, with equality only at x = 2, y = 1; the case already dismissed in the consideration of Ȝ(n) dividing n. Therefore, k = 2, as was to be shown. To complete the proof, we have only to observe that since p and q are both odd primes, ĳ(n)/Ȝ(n) is necessarily an even integer.

Reference 1.

DELAURENTIS, J. M., ‘A further weakness in the common modulus protocol for the RSA cryptoalgorithm,’ Cryptologia, vol. 8, 1984, pp. 253–259.


40 Application-Private Networks

Jonathan M. Smith

Introduction The design space for network architectures can be conveniently described as a 3tuple of <Application requirements, Protocol elements, Network conditions>. Application requirements can range from reliability and small-message interarrival delay to communications secrecy. Protocol elements include acknowledgements and error-correcting codes, timers, and a variety of cryptographic transformations. Network conditions include delay, delay variance, loss rates, bit error rates (BERs), topology, and available bandwidths. For any given triple, and in particular for a choice of application and requirements, we make assumptions about operating conditions, and protocol elements selected to meet the application requirements under these conditions. Two examples, the telephone network and the Internet, are useful in understanding this architectural framework. The telephone network in its purest form is engineered [1] to deliver a band-limited audio channel appropriate for interactive voice telecommunications. The application requirements, then, include the ability to deliver about 3000 Hz of audio, with some limits on delay and audible impairments. These requirements have been met in the telephony architecture by using a call set-up protocol of considerable complexity to establish a point-topoint channel for carrying a voice stream. Link, multiplexing, switching, and capacity engineering are voice-centric. The Internet design, requiring interoperation across a variety of networks and operating conditions, and intended to service many applications, must choose protocols that can tolerate an extremely wide variety of network conditions. Thus, the basic IP transport service is a minimal datagram service, response to network dynamics such as topology changes is provided by dynamic routing, and other application requirements (ordering, reliability, etc.) are provided by endto-end overlay protocols, such as the Transmission Control Protocol, TCP. If we contrast the Internet architecture with the telephony network architecture, TCP/IP is intended to be agnostic with respect to applications, and adapts to a large (but not all-encompassing) range of network conditions with its choice

274

Smith

of protocol elements. To optimize the placement of protocol functions in the architecture (rather than for a specific requirement), the “end-to-end” design notion pushes functions to the end-points, eliminating redundant implementation and giving application designers the widest range of options for use of the basic network service. These two examples illustrate the design space and tradeoffs made amongst its “dimensions.” Neither architecture is ideal. For example the attempt to remove many dynamics in network conditions within the call makes the telephony architecture limited in its ability to efficiently handle applications with dynamics very different than that of voice. Likewise, the approach to dealing with many applications and network conditions in the IP architecture has forced engineering tradeoffs, such as substantial over-provisioning (to control delay jitter) to support applications such as voice and video.

Automated optimal-network engineering An ideal network architecture, within the constraints of our design space, would have the property that at any given time, the application requirements and network conditions would result in the best known selection and placement of protocol elements. For example, if network-condition dynamics result in a variable BER, as in a mobile wireless context, the protocol architecture might be adjusted to inject forward error correction (FEC) to move TCP/IP into an operating regime where its protocol element selections result in meeting application requirements. While limited instances of such techniques have been demonstrated experimentally [4], the ideal system would automate [6] such responses, under control of high-level models of application requirements. A great deal of detail is masked by the design-space abstraction presented in the Introduction, but the basic point is not to be lost: for any specified application requirements (including preferences, weights, etc.) and network conditions (we will discuss how information about such network conditions might be made available using the “Knowledge Plane” proposed by David Clark [3] in the next section), one or more equivalent selections of protocol elements can be made which closely meet the application requirements. As this process is fundamentally driven by application requirements, we call such networks ApplicationPrivate Networks, or APNets. The basic design process for an APNet, for a particular application, would result in a protocol architecture optimized for that application’s performance, with protocol elements selected in concert with any techniques, such as time-division multiplexing, needed to limit the range of network conditions for these selections. The resulting network architecture is colloquially called a “stovepipe.” An excellent example design from the space-systems domain is the “Remote Agent” [6] architecture used in NASA’s Deep Space One (DS1) mission, where many of the challenges are similar to those of network engineering, such as mul-

Application Private Networks

275

tiple timescales, unplanned events, and overall “mission goals.” In the NASA system, very high-level models are used to drive a planning system; current conditions are fed into a system with a limited time horizon to drive specific actions such as recovery, reconfiguration, and reprogramming in the face of system conditions such as failed sensors and actuators. The challenge in the more general case is large-scale sharing. That is, stovepipe design is economically inefficient, inhibits adaptation and reuse, and makes interoperability with other applications, as well as sharing of facilities, difficult. Further, it makes unfounded assumptions for the general case, where conflicting goals between users are common. The advent of programmability in many network components, such as network processors, software radios, and extensible routers, permits the configuration of such components to be virtualized. That is, the component behaviour can support multiple application-driven specializations. The problem is not easy, but is conceptually within reach [6], as demonstrated by the DS1 experiments we have discussed. An abstraction is given in Figure 1a, where application requirements (specified, perhaps, as in the next section) induce behaviors at various logical levels in a network, from host to link. This process will take place repeatedly according to changes in network conditions. The reconfiguration process must be safe, network knowledge must be available to both the protocol element selection and programmable component configuration processes, and the network knowledge must be trusted, to deal with accidental and malicious failures.

Application Requirements Reflective

Middleware O.S. IP Stack Switches Links (a) APNet Configuration

Deliberative Reactive

A P N e t

(b) Controlling APNet Dynamics

Figure 1: APNets

Among the interesting technical questions to be resolved are issues of security, stability, and degree of extensibility for the architecture as a whole. To touch just briefly on these issues, the degrees of extensibility might include those

276

Smith

possible from a machine-learning algorithm in optimization of protocol selections, they might include addition of new protocol elements as they are discovered, or they might include wholesale changes of the control architecture itself. Stability issues include overreactions, damping, and convergence of distributed control schemes. Prototyping and experiments can identify the appropriate adaptation rates for various timescales, ranging from the immediate to relatively longterm, which some researchers have categorized as reactive, deliberative, and reflective —Figure1b illustrates how these adaptation timescales might affect the dynamics of APNet instances. Security concerns, in addition to the trust of network condition data, include the risk of subtle denial-of-service attacks on a complex infrastructure, data privacy, authorization for code loading, provenance of aggregated data, and finally, the technically difficult issue of what the telephony industry politely refers to as “feature interaction.”

Trust architecture for network knowledge The interaction between the knowledge plane and APNets is important, and if network knowledge is to be widely used, it will be named. Much knowledge will be represented syntactically as strings of the form =, e.g., “bandwidth=64K.” This scheme has been widely adopted, in contexts from scripting languages to WWW “cookies,” and is readily translated to locally convenient representations. An example of such a use of a variable is the TERM variable used to configure terminal handling in some operating systems in concert with a database of information about terminal capabilities. In an APNet, the host operating system might, using the variables specified by the application, configure schedulers, networking stacks, and choose network adapters. The string representation enables use of trust management technology [2] such as the KeyNote system [5], which represents assertions as credentials with authorizers, licensees, and conditions. Public-key technologies are used to build the web of trust, and a compliance checking process is used to test requested actions against the credentials. Consider public keys for rmn and jms77, where jms77’s key is the licensee, rmn’s key is the authorizer, conditions are $file_owner=”rmn” && $filename=”/home/rmn/[^/]*” && $hostname = ”ouse.cl.cam.ac.uk” -> ”true” and the signature is with rmn’s key. Then jms77 is authorized by rmn to access files in rmn’s home directory on a particular host at the University of Cambridge.

This architecture provides capability-like [8] control of resources and robust delegation of authority in spite of distributed control through its use of cryptography to authenticate and authorize remote operations [7], and has many other desirable features. Complete explication would require more space, but among the desirable properties of credentials and a trusted knowledge plane for advanced applications are data provenance, support for micro-payment systems of

Application Private Networks

277

various flavors, authorization for network control, code-loading, resource allocation, and digital-rights management.

Conclusion Application-Private Networks extend the range of dynamics for protocol architectures by dynamically selecting protocol elements to meet application requirements in the face of dynamic conditions. Such a network architecture is not only desirable, it is technically achievable within the next decade. A broad range of new network uses would thereby be enabled.

References 1. 2. 3. 4. 5.

6.

7. 8.

Engineering and operations in the Bell System (2nd ed.), AT&T Bell Laboratories, Murray Hill, NJ, 1983, ISBN 0-932764-04-5. BLAZE, M., FEIGENBAUM, J., AND LACY, J., ‘Decentralized trust management,’ Proc. 17th IEEE Symposium on Security and Privacy, 1996, pp. 164–173. CLARK, D., ‘A new vision for network architecture,’ private communication, September 2002. HADZIC, I.,‘Applying reconfigurable computing to reconfigurable networks,’ Ph.D. Thesis, Department of Electrical Engineering, University of Pennsylvania, 1999. KEROMYTIS, A., IOANNIDIS, S., GREENWALD, M., AND SMITH, J., ‘The Strongman architecture,’ Proc. 3rd DARPA Information Survivability Conference and Exposition (DISCEX III), April 2003, Washington, DC, pp. 178–188. MUSCETTOLA, N., NAYAK, P., PELL B., AND WILLIAMS, B.C., ‘Remote agent: to boldly go where no AI system has gone before,” Artificial Intelligence, vol. 103, no.1–2, pp. 5–48. NEEDHAM, R.M., AND SCHROEDER, M.D., ‘Using encryption for authentication in large networks,” Comm. ACM, vol. 21, no.12, 1978, pp. 993–999. NEEDHAM, R.M., AND WALKER, R.D.H., ‘The Cambridge CAP computer and its protection system,’ in Proc. 6th Symposium on Operating Systems Principles, November 1977, pp. 1–10.


41 Using the CORAL System to Discover Attacks on Security Protocols

Graham Steel, Alan Bundy, Ewen Denney

Introduction Inductive theorem provers are frequently employed in the verification of programs, algorithms, and protocols. Programs and algorithms often contain bugs, and protocols may be flawed, causing the proof attempt to fail. However, it can be hard to interpret a failed proof attempt: it may be that some additional lemmas need to be proved or a generalisation made. In this situation, a tool which can not only detect an incorrect conjecture, but also supply a counterexample in order to allow the user to identify the bug or flaw, is potentially very valuable. Here we describe such a tool, CORAL, based on a previously under-exploited feature of proof by consistency. Proof by consistency is a technique for automating inductive proofs in first-order logic. Originally developed to prove correct theorems, this technique has the property of being refutation complete, i.e., it is able to refute in finite time conjectures which are inconsistent with the set of hypotheses. Recently, Comon and Nieuwenhuis have drawn together and extended previous research to show how it may be more generally applied [4]. CORAL is the first full implementation of this method. We have applied CORAL to the analysis of cryptographic security protocols. Paulson has shown how these can be modelled inductively in higher-order logic [16]. By devising a suitable first-order version of Paulson’s formalism, we are able to automatically refute incorrect security conjectures and exhibit the corresponding attacks. The flexibility of the inductive formalism allows us to analyse group protocols, and we have discovered new attacks on such a protocol (the Asokan-Ginzboorg protocol for ad-hoc Bluetooth networks [2]) using CORAL. In the rest of the paper, we first briefly look at the background to the problem of refuting incorrect conjectures and the formal analysis of security protocols. Then we outline the Comon-Nieuwenhuis method. We describe the operation of CORAL and then show how it can be applied to the problem of protocol analysis. Finally, we describe some possible further work, including some other possible applications for CORAL, and draw some conclusions.

280

Steel, Bundy, Denney

Background The refutation of incorrect inductive conjectures has been studied before, e.g., by Protzen [17], Reif [18], and Ahrendt [1]. Ahrendt’s method works by constructing a set of clauses to send to a model generation prover and is restricted to free datatypes. Protzen’s technique progressively instantiates terms in the formula to be checked, using the recursive definitions of the function symbols involved. It finds many small counterexamples. Rief’s method instantiates the formula with constructor terms and uses simplifier rules in the prover KIV to evaluate truth or falsehood. His method is a marked improvement on Protzen’s, but is too naïve for a situation like protocol checking, where it is not obvious what combination of constructor terms constitutes a possible exchange of messages.

Proof by consistency Proof by consistency was originally conceived by Musser [14] as a method for proving inductive theorems by using a modified Knuth-Bendix completion procedure. It was developed by various authors, [8, 10, 6], for the next fifteen years (see [20] for the story), but interest waned, as it seemed too hard to scale the technique up to proving larger conjectures. However, later versions of the technique did have the property of being refutation complete, that is, able to spot false conjectures in finite time.

The Comon-Nieuwenhuis method Comon and Nieuwenhuis [4] have shown that the previous techniques for proof by consistency can be generalised to the production of a first-order axiomatisation A of the minimal Herbrand model such that A E C is consistent if and only if C is an inductive consequence of E. With A satisfying the properties they define as a Normal I-Axiomatisation, inductive proofs can be reduced to firstorder consistency problems and so can be solved by any saturation based theorem prover. There is not room here to give a full formal account of the theory, but informally, a proof attempt involves two parts: in one, we pursue a fair induction derivation. This is a restricted kind of saturation, where we need only consider overlaps between axioms and conjectures. In the second part, every clause in the induction derivation is checked for consistency against the IAxiomatisation. If any consistency check fails, then the conjecture is incorrect. If they all succeed, and the induction derivation procedure terminates, the theorem is proved. Comon and Nieuwenhuis have shown refutation completeness for this system, i.e., any incorrect conjecture will be refuted in finite time, even if the search for an induction derivation is non-terminating.

Using the CORAL System

281

Cryptographic security protocols Cryptographic protocols are used in distributed systems to allow agents to communicate securely. They were first proposed by Needham and Schroeder [15]. Assumed to be present in the system is a spy, who can see all the traffic in the network and may send malicious messages in order to try to impersonate users and gain access to secrets. Although security protocols are usually quite short, typically 2–5 messages, they often have subtle flaws in them that may not be discovered for many years. Researchers have applied various formal techniques to the problem to try to find attacks on faulty protocols and to prove correct protocols secure. These approaches include belief logics such as the so-called BAN logic [3], state machines [5, 11], model checking [12], and inductive theorem proving [16]. Each approach has its advantages and disadvantages. For example, the BAN logic is attractively simple and has found some protocol flaws, though in other cases found flawed protocols correct. The model-checking approach can find flaws very quickly, but can only be applied to finite (and typically very small) instances of the protocol. This means that if no attack is found, there may still be an attack upon a larger instance. Modern state-machine approaches [13, 19] can also find and exhibit attacks quickly, but require the user to choose and prove lemmas in order to reduce the problem to a tractable finite search space. The inductive method deals directly with the infinite-state problem and assumes an arbitrary number of protocol participants, but proofs are tricky and require days or weeks of expert effort. If a proof breaks down, there have previously been no automated facilities for the detection of an attack.

Implementation Figure 1 illustrates the operation of CORAL, built on the SPASS theorem prover [23]. The induction derivation, using the Comon-Nieuwenhuis method as described above, is pursued by the modified SPASS prover on the right of the diagram. As each clause is derived, it is passed to the refutation control script on the left, which launches a standard SPASS prover to do the check against the IAxiomatisation. The parallel architecture allows us to obtain a refutation in cases where the induction derivation does not terminate, as well as allowing us to split the process across multiple machines in the case of a large problem. Experiments with the system show good performance on a variety of incorrect conjectures from the literature and our on own examples [21].

282


Inputs: I-Axiomatization file Problem File I-Axiomatization file

Problem file

All generated clauses (via sockets) Refutation control client

Induction derivation SPASS

File for each Spawned SPASS

(Possibly several)

Standard SPASS

Figure 1: CORAL system operation

Application to cryptographic security protocols Paulson’s inductive approach has been used to verify properties of several protocols [16]. Protocols are formalised in typed higher-order logic as the set of all possible traces. Properties of the security protocol can be proved by induction on traces. However, as Paulson observed, a failed proof state can be difficult to interpret. Even an expert user will be unsure as to whether it is the proof attempt or the conjecture that is at fault. By applying our counterexample finder to these problems, we can automatically detect and present attacks when they exist. The use of an inductive model also allows us to consider protocols involving an arbitrary number of participants in a single round, e.g., conference-key protocols. Paulson’s formalism is in higher-order logic. However, no ‘fundamentally’ higher-order concepts are used—in particular, there is no unification of functional objects. Objects have types, and sets and lists are used. All this can be modelled in first-order logic. The security protocol problem has been modelled in first-order logic before, e.g., by Weidenbach [24]. He used a two-agent model,


283

with fixed roles for participants, and just one available session key and nonce (a nonce is a unique identifying number), and so could not detect certain kinds of parallel session attacks described above. Like Paulson’s, our model allows an indeterminate and unbounded number of agents to participate, playing either role and using an arbitrary number of fresh nonces and keys. Details of the model are in our earlier paper [21], but we will highlight now some recent developments. We have modified our formalism slightly to make attacks easier to find. The idea is to prune out branches of the search space that cannot lead to an attack, or branches which represent a less succinct expression of a state already reached. For example, we merged together the formulae allowing the spy to send a fake message with those for the standard protocol, so that the spy can only send messages which look like a part of the real protocol. Sending anything else cannot fool any honest participants, since they only respond to correctly formed messages. We also have a reduction rule which prunes out clauses which represent states where the spy has sent two messages in a row. The spy can’t gain anything from doing this, so by chopping off these branches we make the search problem more tractable. With these improvements CORAL has rediscovered a number of known attacks, including the well known ones on the Needham-Schroeder public-key and Neuman-Stubblebine shared-key protocols. It can also find the attack on the simplified Otway-Rees protocol, an attack which requires an honest agent to generate two fresh nonces and to play the role of both the initiator and the responder. Recently, CORAL found two new attacks on the Asokan-Ginzboorg protocol for establishing a secure session key in an ad-hoc Bluetooth network [2]. Details of the attacks and a description of how we modelled this group protocol in a general way without restricting to a small fixed instance are in a forthcoming paper [22].

Further work Future work will include testing the CORAL system on more group-key protocols. As CORAL is built on SPASS, a theorem prover capable of equational reasoning, we should be able to reason about some simple algebraic properties of the cryptosystems underlying protocols, such as Diffie-Helman type operations. In particular, Asokan and Ginzboorg have proposed a second version of their protocol that uses these kinds of operations, which would be an ideal candidate for future investigation. There has been a proliferation of protocol analysis tools in recent years, and in the longer term we don’t intend to try and compete with others for speed of attack finding or by analysing an enormous corpus of protocols. Rather, we intend to try to exploit the flexibility of our system as a general tool for inductive counterexample finding and apply it to some other security problems. One idea is to use the system to model security problems at a higher level. We could

284


model a company’s computer network as a system of local networks and servers, firewalls, etc., all with formally defined behaviour, and examine how interactions in the presence of intruders might lead to exploitable vulnerabilities. To deal with larger problems like this, we might need to enhance SPASS to exploit domain knowledge a little more. Two possible ideas we intend to explore are a user-defined strategy that can vary as the proof proceeds and a critics mechanism [9] to suggest pruning lemmas. In theory, CORAL can also show security properties of protocols to be correct when there are no attacks to be found. However, to make this work in practice would require some considerable work. The formulae to be proved are significantly larger than the kinds of examples that have been proved by proof by consistency in the past. The critics mechanism for suggesting lemmas could help with this.

Conclusions We have presented CORAL, our system for refuting incorrect inductive conjectures, and have shown how it can be applied to the problem of finding attacks on faulty security protocols. Our formalism is similar to Paulson’s, which allows us to deal directly with protocols involving an arbitrary number of participants and nonces, and with principals playing multiple roles. CORAL has discovered a number of known attacks, and some new attacks on a group-key protocol. In the longer term, we hope to apply the system to other, related security problems and exploit its ability to do equational reasoning in order to analyse some crytpoanalytic properties of protocols. (This paper is a shortened and updated version of [21]. )

References 1.

2. 3. 4.

5. 6.

AHRENDT, W., ‘Deductive search for errors in free data type specifications using model generation,’ in CADE-18, 18th International Conference on Automated Deduction, 2002. ASOKAN, N., AND GINZBOORG, P., ‘Key agreement in ad-hoc networks,’ Computer Communications, vol. 23, no. 17, 2000, pp. 1627–1637. BURROWS, M., ABADI, M., AND NEEDHAM, R., ‘A logic of authentication,’ ACM Trans. on Computer Systems, vol. 8, no. 1, February 1990, pp. 18–36. COMON, H., AND NIEUWENHUIS, R., ‘Induction = I-Axiomatization + First-Order Consistency,’ Information and Computation, vol. 159, no. 1–2, May/June 2000, pp. 151–186. DOLEV, D., AND YAO, A., ‘On the security of public key protocols,’ IEEE Trans. in Information Theory, vol. 2, no. 29, March 1983, pp. 198–208. GANZINGER, H., AND STUBER, J., ‘Inductive theorem proving by consistency for firstorder clauses,’ in Rusinowitch, M. and Rémy, J.J., (eds.), Proc. 3rd International


7.

8.

9. 10. 11. 12. 13. 14. 15.

16. 17.

18. 19. 20. 21.

22.

23. 24.

285

Workshop on Conditional Term Rewriting Systems, Pont-à-Mousson, France, Springer, LNCS vol. 656, pp. 226–241. GANZINGER, H., (ED.), Automated deduction, CADE-16: 16th International Conference on Automated Deduction, Trento, Italy, July 1999, Lecture Notes in Artificial Intelligence 1632, Springer-Verlag. HUET, G., AND HULLOT, J., ‘Proofs by induction in equational theories with constructors,’ J. of Computer Systems and System Sciences, vol. 25, no. 2, 1982, pp. 239– 266. IRELAND, A., ‘Productive use of failure in inductive proof,’ J. of Automated Reasoning, vol. 16, no. 1–2, 1996, pp. 79–11. JOUANNAUD, J.-P., AND KOUNALIS, E., ‘Proof by induction in equational theories without constructors,’ Information and Computation, vol. 82, no. 1, 1989, pp. 1–33. KEMMERER, R., MEADOWS, C., AND MILLEN, J., ‘Three systems for cryptographic protocol analysis,’ J. of Cryptology, vol. 7, 1994, pp. 79–130. LOWE, G., ‘Breaking and fixing the Needham Schroeder public-key protocol using FDR,’ in Proc. TACAS, LNCS 1055, Springer Verlag, 1996, pp. 147–166. MEADOWS, C., ‘The NRL protocol analyzer: An overview,’ J. of Logic Programming, vol. 26, no. 2, pp. 113–131, 1996. MUSSER, D., ‘On proving inductive properties of abstract data types,’ Proc. 7th ACM Symp. on Principles of Programming Languages, 1980, pp. 154–162. NEEDHAM, R.M., AND SCHROEDER, M.D., ‘Using encryption for authentication in large networks of computers,’ Comm. ACM, vol. 21, no. 12, December 1978, pp. 993–999. PAULSON, L.C., ‘The inductive approach to verifying cryptographic protocols,’ J. of Computer Security, vol. 6, 1998, pp. 85–128. PROTZEN, M., ‘Disproving conjectures,’ in Kapur, D., ed., CADE-11: 11th Conf. on Automated Deduction, Saratoga Springs, NY, June 1992. Springer, Lecture Notes in Artificial Intelligence 607, pp. 340–354. REIF, W., SCHELLHORN, G., AND THUMS, A., ‘Flaw detection in formal specifications,’ in IJCAR’01, 2001, pp. 642–657. SONG, D., ‘Athena: A new efficient automatic checker for security protocol analysis,’ Proc. 12th IEEE Computer Security Foundations Workshop, 1999. STEEL, G., ‘Proof by consistency: A literature survey,’ March 1999. http://homepages.inf.ed.ac.uk/s9808756/papers/lit-survey.ps.gz STEEL, G., BUNDY, A., AND DENNEY, E., ‘Finding counterexamples to inductive conjectures and discovering security protocol attacks,’ Proc. of the Foundations of Computer Security Workshop, 2002, pp. 49–58; also in Proc. of the Verify ’02 Workshop. Also available as Informatics Research Report EDI-INF-RR-0141. STEEL, G., BUNDY, A., AND MAIDL, M., ‘Attacking the Asokan-Ginzboorg protocol for key distribution in an ad-hoc Bluetooth network using CORAL,’ to appear in Proceedings of FORTE 2003 (work in progress papers). WEIDENBACH, C., ET AL., ‘System description: SPASS version 1.0.0,’ in Ganzinger [7], pp. 378–382. WEIDENBACH, C., ‘Towards an automatic analysis of security protocols in first-order logic,’ in Ganzinger [7], pp. 314–328.


42 On the Role of Binding and Rate Adaptation in Packet Networks

David Tennenhouse An ongoing debate within the network research community concerns the degree to which packet switching, especially that which is IP-based, can and should subsume other types of networks, e.g., those based on circuit switching. In this short paper, I discuss four aspects of this debate that have long been of concern to me as a network researcher: • The tendency of network architects to focus on the “core” of the network, which is its least interesting architectural component. • The common misconception that statistical multiplexing is the fundamental advantage of packet switching. • The proposal that late binding and rate adaption are the essential architectural advantages of packet switching. • The observation that it is the properties of key interfaces, rather than the network internals, that are most deserving of our attention. While much of what follows will be very familiar to software and systems researchers, these concepts do not seem to be as well accepted within the networking community.

The “core” is architecturally irrelevant Much of the recent discussion has been focused on the degree to which IP, and packet switching in general, will directly support the underlying transport infrastructure, sometimes referred to as the “core,” or “cross-connect,” of national scale multi-service networks. While some would argue that it can and should, others conclude that “the core of the network will use optical circuit switching as a platform for multiple services,” [1]. I find the question of packet vs. circuit operation of the underlying crossconnect rather tedious for these reasons:

288

Tennenhouse

• •

The topology of the physical media comprising the core is relatively simple and rigid. For example, in the United States, the national scale “core” has on the order of hundreds of nodes. The statistical properties of the highly aggregated, or “groomed,” crossconnect channels will be relatively predictable and slow to evolve. Since the time constants involved are quite lengthy, relative to the round-trip times within the core, the choice of packet vs. circuit crossconnect is a moot point.

But isn’t statistical multiplexing the essence of packet switching? The focus on the behavior of the core suggests that there is a deep misunderstanding as to the essential merits of packet networks in general, and the Internet in particular. Molinero-Fernandez et al. [1]—and many others in the network research community—ground their reasoning in the following premise: From the early days of computer networking, it has been well known that packet switching makes efficient use of scarce link bandwidth. With packet switching, statistical multiplexing allows link bandwidth to be shared…

While the above position is widely held, I find the frequent and very loose generality with which it is applied disconcerting. In particular, the importance and relationship of the words “scarce” and “statistical” are almost always disregarded—as are the time constants involved. Both circuit- and packet-switched networks take advantage of statistical multiplexing, with the only real distinction being the time constants.1 Per-packet statistical multiplexing is of marginal utility if the traffic is steady over long periods and/or the bandwidth is continuously exhausted. The same is true at the other extreme, i.e., when bandwidth is not scarce as a consequence of over-provisioning. Packet multiplexing is beneficial within a limited range of statistical patterns and scarcities, typically observed near the edge of the network. It can be highly advantageous at “early multiplexing” points, where modest numbers of relatively dynamic flows are multiplexed into larger aggregates. At these points the bandwidth available to the aggregate may well be scarce relative to the statistical properties of the individual tributaries. At switching points deep within the core of a national scale multi-service infrastructure, the traffic on each channel is derived from the aggregation of vast numbers of flows. These highly aggregated cross-connect channels will be statistically “smoother,” and this has a huge impact on the nature of bandwidth scarci1

Circuit switched telephony has long relied on statistical properties of call attempts, call duration, etc. Interestingly enough, the signaling system used to setup calls is, itself, a packet-switched network.

On the Role of Binding

289

ties at the switching points and the potential of any architecture to respond to them. • Many types of core scarcities can be anticipated months in advance and dealt with through provisioning. • Large-scale unanticipated scarcities, such as those arising from simultaneous failures and/or coordinated surges in demand, will force any architecture into a “degradation” mode, whose desired behavior will be more a matter of public policy than architectural finesse. • Most intermittent scarcities falling between the above extremes will have sufficiently long time constants that the distinction between circuit and packet switching may not be relevant. Although some have suggested that IP traffic might be clumped or correlated, recent measurements [2] suggest that channels within the core experience relatively small and predictable delays over the time constants of interest.

Dynamic binding and rate adaptation: the real essence of packet switching So what, then, is the architectural advantage of packet switching? While I concede the importance of statistical multiplexing at moderate aggregation levels, I have never believed it to be the architectural imperative.2 I suggest that the real “magic” of packet switching, especially with respect to the operation of multiservice networks, lies in two properties: late binding and rate adaptation.

Binding Packet-based interfaces multiplex a very large number of logical channels onto a “bearer” channel. In the case of IP, there is a separate logical channel for each unique <source address, source port, destination address, destination port, protocol type> tuple.3 On any given link, this IP channel space is very sparsely populated, i.e., the vast majority of the logical channels are unused. The bindings for those that are used is highly dynamic: for the most part, the application(s)—and therefore the properties of the traffic—associated with a logical channel are determined at run time; and the bindings between a logical channel and the underlying capacity of the bearer channel are determined on a packet by packet basis. The latter aspect by itself might be construed as “statistical multiplexing.” How2 3

On this specific issue, I must admit to having reached an impasse with many distinguished experts, most notably my friend and mentor Robert Kahn. As evidenced by NAT, these tuples are only unique at the interface points. Also, there is a slight simplification here, owing to the semantics associated with multicast addresses and some protocol types.

290

Tennenhouse

ever, the combination of the two degrees of binding freedom, within the context of a vast logical channel space, is a broader architectural feature that allows IPbased interfaces to function as a “universal solvent”4 enabling multi-service interfaces.

Rate adaption This property of packet switching, typically realized through the use of elastic buffers of some sort, allows applications at an endpoint, whose network point of attachment operates at one rate, to communicate with peers whose points of attachment may operate at arbitrarily different rates—many orders of magnitude different in the case of a modem-attached client vs. a data center server. Rate adaptation, over an enormous dynamic range, is one of the most significant advantages of packet switching and its key “trump card” with respect to both multiservice networking and the Internet’s ability to absorb rapid innovation, e.g., by ensuring that faster nodes and links seamlessly inter-operate with the embedded base. Rate adaptation is particularly advantageous in closed-loop scenarios where the traffic patterns of individual packet flows can be dynamically shaped in response to changing network and endpoint conditions. In the case of TCP/IP, rate adaption is enhanced through the combination of lower-layer queues (the elastic buffers) and the TCP layer end-to-end control mechanism, which ensures that the long-term flow of packets is matched to the capacity of the endpoints and of all of the intervening queues along the path. In the simple case of a human user accessing data via a Web browser, TCP feedback controls the flow of data during each transaction, and an outer feedback loop, closed by the human user, governs the overall rate of request submission, i.e., as response time deteriorates, the rate at which new requests are submitted to the system declines. Unfortunately, some types of “real-time” traffic, especially legacy sample streams derived from the physical world around us,5 are not readily amenable to feedback-based shaping. Nonetheless, these sources of traffic still benefit from the architectural advantages of rate adaptation. Furthermore, the highly predictable statistical properties of the traffic in question (which are determined by the sampling and compression mechanisms used) may amplify the task of dimensioning the packet network appropriately.

4 5

I am indebted to my colleague Vint Cerf for this wonderful metaphor. Which can not easily be “slowed down.”


291

It’s the interfaces that count Returning to the underlying question, the degree to which IP can be the basis of national-scale multi-service networks, one must first identify the key points at which this question should be considered. That is, if the “core” of a future multiservice infrastructure isn’t of architectural interest, then what is? An important step towards answering this question may be to view IP not so much as the basis for a homogeneous soup-to-nuts6 infrastructure, but as the common protocol “stack” used at a few key classes of interoperability points. Ethernet presents a useful, though limited, analogy here. At one stage, the term Ethernet referred to the design of an entire LAN. Today, what really matters is a few core architectural concepts and their embodiment at the interoperability points. The fact that many different technologies, including wireless, are now used to realize these concepts is of little importance. All that matters at the individual endpoints is that the NIC driver presents an interface that approximates that of the original standard. Given this perspective, there would appear to be three distinct classes of IP interfaces to be considered: • The interfaces to individual client nodes and the “early” multiplexing points at which client traffic is multiplexed onto larger aggregates. • Interfaces (at or near edges) that are very highly multiplexed, i.e., that support large numbers of active logical channels. In contrast to its initial implementation, today’s Internet is highly asymmetric with a small fraction of the nodes (e.g., Akamai sites, MSN, Google, etc.) terminating a large fraction of the flows. • Interfaces that bridge peer Internet service providers. Although the initial architecture envisaged a “catanet,” formed through the concatenation of independently operated networks, today’s Internet supports a significant degree of service-provider diversity, i.e., core networks operating in parallel with each other. In a multi-service environment, is it feasible for all three types of interfaces to be IP-based? Independent of whether or not IP is the best way to structure those interfaces, do we see any fundamental limits to the “absorption” of new types of traffic at those interface points? If there are merely impediments (vs. fundamental limits), then are they of sufficient economic importance to fund the emergence of an alternative interoperable stack in the near future? Although IP may have some unsightly warts, I am hard pressed to find any of them to be fundamental or even so serious as to create a high enough barrier to offset the power of incremental refinement fuelled by the investment engine driving IP. The continued growth of Voice over IP, especially within increasingly cost-conscious enterprises, is but one example of that engine at work.

6

More precisely, edge through core.

292

Tennenhouse

The interesting question, then, may be not whether IP can continue to absorb new classes of traffic, but how features “around” these three classes of interfaces, and related aspects of the protocol suite, might evolve and/or become increasingly specialized to improve the ability of IP-based networks to absorb new types of services: • Can the “early multiplexing points” of the Internet be engineered and/or mutate sufficiently to absorb new types of traffic/media at the edges of the network? My best guess is that it can and, for the most economically relevant traffic, will. As an alternative to some of the complex QoS schemes under consideration today, one could easily imagine all of the traffic at these interfaces falling into one of two distinct classes, each of whose handling could be independently provisioned and routed: traffic that is amenable to shaping through feedback and traffic whose statistcal properties are highly predictable.7 • What opportunities for specialization exist at the heavily multiplexed interfaces? This is an especially tantalizing question, since there may be a considerable degree of homogeneity with respect to the types of services carried on the logical channels of these interfaces. • Are there obvious specializations that would simplify the implementation of peering interfaces, which are very high volume ingress/egress points? What mechanisms can be introduced to support cross-provider implementation of policy-based requirements, such as the prioritization of traffic during civil emergencies? Can virtual circuit techniques, such as MPLS, simplify the processing at these interfaces and/or improve their robustness to failures, e.g., by making it easier to simultaneously re-route large aggregates? Notwithstanding the feasibility of retaining an IP-based approach, might the relatively small numbers and high value of these interfaces be sufficient to support enhanced architectural diversity at these points?

Summary In this note I have attempted to identify some of the key architectural advantages of packet-based network interfaces. Could we have arrived at a slightly better architectural solution with a different packet-based protocol suite? Probably. Does it matter? I think not. Does that mean IP is the end of the road for network research? Of course not!

7

Additional distinctions may be useful within the endpoints, e.g., to distinguish foreground and background activities.


293

References 1. 2.

MOLINERO-FENANDEZ, P., MCKEOWN, N., AND ZHANG. H., ‘Is IP going to take over the world (of communications)?’ HotNets ’02, Princeton NJ, October 2002. PAPAGIANNAKI, K., MOON, S., FRALEIGH, C., THIRAN, P., TOBAGI, F., AND DIOT, C., ‘Analysis of measured single-hop from an operational backbone network,’ IEEE Infocom, New York, NY, June 2002.


43 Technologies for Portable Computing: Outlook and Limitations

Chuck Thacker The last few years have produced a proliferation of new portable computing devices. We now see a wide variety of personal digital assistants, digital cameras, digital media players, tablet PCs, and wireless phones. Many of the technologies employed in these devices have improved as predicted by Moore’s Law,1 but some are more mature and improve much more slowly. In this paper, I will examine the current state of the art in power and cooling technology, processors, displays, nonvolatile storage, and wireless networking in an attempt to understand the possible directions for portable devices over the next few years. I also discuss the characteristics of several devices that have employed leading-edge technologies.

Power and cooling Supplying the necessary power and removing the resulting heat has been the largest problem in portable-device design. Currently, all portable computing devices are operated from batteries, with the vast majority employing rechargeable cells. Over the last decade, battery technology has improved somewhat, from the early nickel cadmium cells to nickel metal hydride to lithium ion, but the energy density available from a modern lithium ion battery is only about 120 watt-hours per kilogram, and this has not improved significantly in the past three years. For low-duty cycle devices such as mobile phones or PDAs, which dissipate only a few milliwatts when idle, lithium ion batteries provide several days of use between charges at an acceptable weight. For more demanding applications such as laptops, battery life is typically much less than a working day, which requires that the user carry a charger or extra batteries. 1

Gordon Moore, Intel chairman, said in 1965 that transistor densities would double every 18 months for the foreseeable future. Thirty-five years later, this “law” still holds, and is expected to do so until the end of the decade.

296

Thacker

The primary technology that may improve this situation is fuel cells. Hydrogen fuel cells have been used in military and space applications for decades, but these devices are complex, expensive, and operate at high temperatures. Two new variants, the proton exchange membrane (PEM) [1] and direct liquidmethanol (DLM) cells, use methanol as the fuel and operate at room temperature. These devices provide energy densities somewhat higher than lithium-ion cells and can be refueled from cartridges. A number of research laboratories and companies are exploring this technology, but products are likely to be two to five years away. Practical cooling alternatives include passive techniques that distribute the heat generated by the electronics to the device’s case and active cooling using fans. The former solution is quite limited in the amount of heat that can be removed successfully—the Microsoft tablet PC, for example, dissipates a peak power of about 14 watts, and even though the heat is spread fairly uniformly over the rear surface of the device, the case can become uncomfortably warm. Fortunately, peak performance is rarely needed by today’s applications,2 so this situation is infrequently encountered. The use of fans is typical in both the largest and smallest portable computers. Today’s large laptops make use of desktop-class x86 CPUs, which must be actively cooled. Although the smaller devices make use of lower-powered processors, their radically reduced surface area makes passive cooling impractical.

Processors While “traditional” laptop computers have chosen to employ desktop-class x86 processors in spite of their high power and stringent cooling requirements, both recent “thin and light” laptops and smaller devices with new form factors have opted for lower powered but slower processors. For devices that run Windows XP, x86 compatibility is mandatory. Until recently, the primary sources for low-power x86 CPUs were Transmeta and National Semiconductor. Transmeta uses a combination of interpretation and dynamic compilation which they call “code morphing” to run x86 programs on a VLIW core that is considerably simpler than a typical x86. The results of the compilation are held in a region of the system’s RAM that the CPU reserves to itself. While this technique works well for applications (e.g., audio and video codecs) that contain loops, starting an application involves interpreting the code, which makes the CPU appear slower than it actually is. Transmeta processors draw between 1.5 and 8 watts, depending on load. National Semiconductor has approached the low-power market with its Geode family of x86 processors. The Geode GX2 operates between 200 and 333 2

Although the use of speech recognition and other energy-intensive user-interface techniques may worsen this situation in the future.

Technologies for Portable Computing

297

MHz, and dissipates a maximum of 5 watts, with “typical” power between 0.8 and 1.4 watts. Intel has recently responded to competitive threats with its Banias processor, but details of its power consumption are still sketchy. For devices that do not need to run Windows XP, several energy-efficient options are available. Intel’s XScale processor (PXA 250), based on the DEC StrongArm, operates at 400 MHz, while dissipating 750 mW. The AMD Alchemy Au1100, a MIPS-architecture machine, operates at 500 MHz and dissipates 500 mW. These devices are considerably more energy-efficient than an x86 of comparable performance because of their simpler structure and an emphasis on efficiency rather than maximum clock rate. Dynamic voltage and frequency scaling have also proven valuable in reducing CPU power. These schemes3 reduce the clock rate and the supply voltage during periods of light computational load. Since dynamic device power is linear in clock frequency and quadratic in supply voltage, small changes can have dramatic effects (~3×) on device power. One problem that may limit the achievable power reduction in future processors is leakage current. As device sizes become smaller and supply voltages decrease, static leakage current becomes an increasing fraction of the device current. A substantial amount of architectural research is underway to mitigate this problem by gating clocks and powering down entire functional units when they are not needed.

Displays Today, liquid crystals are the only choice for portable displays. LCDs have undergone intense development to reduce their cost and increase their size, but there has been little progress on increasing the robustness and brightness of LCD panels. Display breakage is still an almost inevitable result of dropping a laptop, and few laptops can be used outdoors due to their low brightness. Some pocket PCs have employed transflective displays with front rather than back lights to make outdoor use possible, but these devices suffer from extremely poor contrast ratios, which makes reading quite difficult. The display subsystem and its backlight consume about half the power drawn by a modern “thin and light” laptop, or about 5 watts. This power is to a large extent proportional to the area of the display, so it is much less in smaller devices. From a battery-life perspective, an unfortunate trend is that graphical user interfaces are making increasing use of 3-D effects and animation. This increases

3

Called “speed step” by Intel and “long run” by Transmeta.

298

Thacker

the power consumed by the system’s graphics controller substantially, similar to the way in which speech recognition and other real-time tasks increase the power demands on the CPU. The most likely replacement for LCDs is a display based on organic lightemitting diodes (OLEDs). The necessary organic polymers have existed for several years, but there has been relatively slow progress in turning these materials into commercially viable displays. The leading manufacturers of these materials are Cambridge Display Technologies (CDT) [2] and Kodak [3]. The latter has recently entered a partnership with Sanyo to exploit their materials. OLED panels are likely to be brighter and have a larger viewing angle than LEDs for a given power level, and can potentially be much more robust, since they do not need to be transparent and can be fabricated on a metal substrate. Unfortunately, the electronics associated with each pixel are more complex than in an LCD. In LCDs, a single transistor serves to set the voltage of each pixel, which acts as a capacitor. This is similar to the arrangement in a single-transistor DRAM cell. In an OLED, each pixel must include circuitry to provide a varying level of current through each diode during the entire frame time. This requires at least two transistors—one to do the multiplexing and one to do voltage-tocurrent conversion. These devices, as in a thin-film-transistor LCD, must be fabricated on a glass substrate, and doing it at acceptable yields has eluded manufacturers. Although CDT initially (1998) predicted commercial OLED panels in 2001, most manufacturers are now indicating that the devices will not be competitive with LCDs until 2005.

Nonvolatile storage Disk storage has exceeded Moore’s law in density increase for the past few years. The current state-of-the-art disk for portable devices is a Toshiba 1.8" drive that is the size of a credit card, has a capacity of 20 Gbytes, an areal density of 22.4 Gbits/in2, and consumes only 1.4 watts. These devices are intriguing, as they enable portable devices that contain all of the digital state for a single user. Allowing users to make their state available on any of the computers with which they normally interact might be an attractive alternative to the complex synchronization and copying that is the norm today. Ultimately, experts believe that magnetic disk density will soon be limited by the “super paramagnetic limit,” at which individual domains can be switched by thermal noise. Current estimates for this density are on the order of 100 Gbits/in2, which corresponds to 80 × 80 nanometer bits. A number of companies are exploring the use of microelectronic-mechanical systems (MEMS) to overcome magnetic density limitations. Researchers at IBM [4], for example, have demonstrated their ability to record and read data at a terabyte per square inch, using a heated atomic-force microscopy (AFM) probe


299

to melt nanometer-scale pits in a polymer medium. Hewlett-Packard and a small startup company called Nanochip [5] are both building similar devices. All of these devices are similar in that they move either the probes or the medium in x and y using actuators that are fabricated using normal semiconductor processing. IBM uses electromagnetic actuators, HP uses electrostatic motors, and Nanochip uses a technique that exploits the thermal expansion of heated wires. Because the devices have a large number of probes, the required motion is small—on the order of 100 µm. The medium (in the IBM device) or the probe array (in the Nanochip device) is supported by springs that are fabricated at the same time as the actuators. The Nanochip device is shown in Figures 1 and 2. It consists of sixteen independently moveable sub-arrays, each with sixteen probes.

Figure 1: One of the sixteen Nanochip sub-arrays, showing four actuators and sixteen cantilevered probes.

The IBM device has a low read/write bandwidth (~20 kbits/second per probe), so it must operate hundreds of probes in parallel to provide bandwidth competitive to that of a magnetic disk. This led to their choice of a moving medium and stationary probes. The large number of simultaneously-operating probes also requires the fabrication of on-chip multiplexing electronics. The Nanochip device, which uses a different recording medium that supports higher bandwidth, does not require on-chip active devices.

300

Thacker Substrate

Well 50µ 50µ

Platform 50µ

Cantilevers + Tips (x16) 50µ

Wire Bundles (x4) Thermal Actuators

Pull Rod Bimorph Elements (w/ redundancy)

Figure 2: The Nanochip device in schematic form

While MEMS devices can be built in fabrication facilities that are well behind the state of the art, they are still not expected to be competitive in per-bit cost with magnetic disks. The primary competitor that most MEMS manufacturers hope to displace initially is flash ROM. Flash ROM cells are intrinsically smaller than DRAM cells, and since less stringent testing is required,4 the devices should be cheaper than DRAM, which is now priced at about twenty cents per megabyte. To date, these price levels have not been achieved, perhaps because of lower volumes and lack of sufficient fabrication capacity Ultimately, MEMS storage devices might replace disks in applications that do not require huge capacity, or in applications in which their low power and complete silence are important. The companies developing MEMS storage anticipate having products available in from two to four years.

Networking For portable devices, there is an expectation (largely fueled by the popular press) that wireless networking will improve at a pace similar to the improvement in CPU performance. This seems implausible for several reasons. First, increased transistor density in radios doesn’t translate into higher performance, as it does

4

Flash cells may be erased and rewritten a limited number of times, so error correction is needed for reliability. Manufacturers exploit this by shipping parts with a small fraction of bad bits.


301

in a CPU, but only into reduced cost. Second, the available spectrum is finite, and increased per-connection bandwidth uses more of it. Spectrum use is regulated by local law and international treaty, and current users have resisted attempts to displace their services. Improvements in coding have improved the bandwidth efficiency of radio channels, but these improvements are rapidly approaching their limit. One proposal to mitigate these limits is to use the spectrum at ~50 GHz. These frequencies are strongly absorbed by atmospheric oxygen, so very small cells will be needed for ubiquitous coverage. Providing the necessary wired infrastructure will be costly, and it is unclear that users will be willing to pay for it. For a given cell size, there is also a direct trade-off between power and bandwidth. Current 802.11b radio cards draw approximately 1 watt. Better protocols and better designs can improve this a bit, and the superior modulation used by 802.11g promises a fourfold bandwidth improvement, but these improvements require a smaller cell size.

Example systems Several companies are developing systems designed primarily for small size and energy efficiency. Figures 3 and 4 show two recent examples, the Tiquit EightyThree [6] and a wallet-sized system from OQO Corporation [7].

Figure 3: The Tiqit Eighty Three Computer. This device provides a keyboard, a joystick and a stylus for user interaction.

302

Thacker

Both are full Windows XP machines, with 256 MB of DRAM, 20 Gbyte hard disks, and color VGA (480 × 640) displays. The Tiqit device uses a 300 MHz National Geode processor and is fanless. The somewhat smaller OQO device uses a 1GHzTransmeta CPU and requires a fan.

Figure 4: The OQO Ultra Portable Computer.

A number of other devices that combine the functions of a PDA and mobile phone are also appearing in the market. It will be interesting to see whether these devices become popular, since the user interfaces needed for phones and PDAs are quite different. Although carrying a single device is appealing, finding a single form factor that can serve both purposes might be difficult.

Conclusions The goal of providing a portable, truly personal computer that can provide all the computing, communication, and storage needs of a single user has not yet been achieved, although it seems clear that the underlying technologies needed are very nearly adequate today. The existence of such devices will pose new challenges for software developers: How can we build new user interfaces that provide acceptable levels of interaction with a very small display? How can we provide an easy-to-use user authentication system that protects the user’s data if the device is lost or stolen,


303

or that makes a stolen device unusable? How should these devices interact with the larger world of computing of which they are only a small part? Providing software and services for these devices will provide new opportunities for innovation in many areas of computing.

References 1 2 3 4 5 6 7

http://www.sciencenews.org/20020907/bob10.asp http://www.cdtltd.co.uk http://www.kodak.com/US/en/corp/display/whatsNew.jhtml VETTIGER, P., ET AL., ‘The ‘Millipede’—nanotechnology entering data storage,’ IEEE Trans. Nanotechnol., vol. 1, no. 1, 2002, pp. 39–55. http://www.nanochip.com http://www.tiquit.com http://www.oqo.com


44 Multiple Alternative Voting

David Wheeler This paper was the result of discussions with Roger Needham in April 1983. The University of Cambridge was intending to introduce single transferable voting for official ballots, and did so, even though this method has the defects discussed below. More generally, since then electronic voting has become a public policy issue. It is evident that there are more complexities about this, both in principle and in practice, than many may suppose (see, e.g., Mercuri [1]). What follows is an early note on some pertinent problems. Voting is also widely used, for many different technical purposes, in computing systems, and the note implicitly also draws attention to the need for care in the choice of algorithms in these technological contexts.

STV and MAV in brief The single-transferable-vote system (STV) suffers from one major fault. As it is a single-vote system, it uses the second and remaining choices of a voter in an algorithmic but arbitrary way when more than one vacancy is being filled. This fault can be eliminated with an alternative strategy, multiple alternative voting (MAV), while retaining the advantages of STV. (The two methods are identical when there is a single vacancy.) In MAV, each voter gives a preference list for the candidates, just as for STV. If there are V vacancies, then one vote is counted for each of the first V preferences of each elector. The candidate with the lowest vote is eliminated from all the preferences and the count repeated until only V candidates remain.

The problems with single transferable voting The major objection to the STV system is that the second and higher preferences are used in an arbitrary way. That is to say, the voter does not know if or how his

306

Wheeler

preferences are to be used. This arises because the method uses a quota, the minimum number of votes needed to elect a candidate. If the first preference is part of an exact quota, the voter’s later choices are unused. This is reasonable for a single vacancy, but not for multiple vacancies, where surplus preferences are reassigned without voter control.

Example Assume 303 voters filling 3 vacancies from 5 candidates, namely A, B, C, D, E. Assume the votes are cast as follows: 76 voters list A, D, E 76 voters list B, D, E, C 76 voters list C, D, E, B 75 voters list D, E, A With STV, calculation of the quota = 303/4 + 1 = 76. Thus A, B, and C are elected.

Multiple alternative voting Now consider another strategy, multiple alternative voting. To calculate MAV, suppose the votes cast are these: A B C D E vote sums 151 76 76 303 303 Use the tie rule and delete, say, B from the ballots. Thus 76 fourth preferences for C are used, giving the following voter sums: A B C D E 151 0 152 303 303 Thus D, E, and C are elected. If no one cast fourth preferences, then D, E, and A are elected. Given the illustrative voting figures and all the preferences, one would expect D and E to be elected and an extra one from A, B or C. However, STV gives A, B and C, and not D or E at all, because it only considers first preferences, with its arbitrary quota. How does an STV voter indicate he wishes to select three candidates with about the same weight? He cannot, because he is at the mercy of the arbitrary quota. The example just given shows how the MAV strategy is more nearly in accord with what the electors might expect, and how the information from them is used more effectively. The average elector would expect his first V preferences to be used if he filled them in. He would expect that if a candidate of his were defeated, then his next preference would be used. He would not expect that the use of his preferences would depend on the arbitrary quota.

Multiple Alternative Voting

307

A few might expect that a single vote would carry more power than if it were split among V candidates. However, this is really a matter of philosophy, and the system is simpler if we arrange that when voters use less than V votes, their votes do not carry greater than unit weight. This means also that when preferences run out for a voter because his early preferences have been rejected, his residual votes do not carry more than unit weight. In no case yet found does the MAV result appear to be further from what can be claimed to be the voters’ intentions and expectation than the STV system in any of its forms. When there is a single candidate, the two systems will give identical results unless the tie arrangements are different. We now give a more detailed description of the MAV system.

MAV in detail Voter’s ballot form This consists of a list of candidates, preferably in random order. Each item in the list consists of the candidate’s name followed by a box or space for an integer.

Voter’s instructions Mark your first preference with 1 in the box of the candidate you prefer. Mark your second preference with 2 in the box of your second choice. And so on. If fewer than the number of vacancies are filled in, then the empties are taken as abstentions and the effectiveness of the earlier votes is unchanged.

Counting rules Assume there are V vacancies. The first V unrejected candidates on each voter’s list are each given one vote. If V or fewer candidates have non-zero vote sums, these are elected, otherwise the candidate with the least vote sum is rejected and the count is repeated. Ambiguities are resolved by rejecting the candidate with the least number of first preference votes, then, if still unresolved, using the second, third, etc., preferences. The ambiguities remaining are resolved by algorithmically tossing a coin so that it cannot be “forced.” For example, one such rule is to divide the total number of votes by the number of choices to be made and use the remainder to select the candidate to be rejected.

308

Wheeler

Printed results First give the sums for each candidate, i.e., the number of votes for candidate A with mark 1, the number of votes for candidate A with mark 2, and so on. Then add the number of votes transferred from the rejected candidate to each of these sums. This is repeated until the final sums for the elected candidates can be given. (One null candidate should be included to simplify the treatment of null votes.) The above suffices for the simple system. However a number of extra points arise.

Printed list of voters Should a list of those who have voted be published? It can help in detecting fraud.

Printed lists of votes cast This can be done anonymously if every ballot paper has a unique reference number by the side of each candidate. A list can be published for each candidate and mark. The list contains the reference numbers of each vote cast for that candidate and the mark. Only the user of the ballot paper and the central counting procedure (probably a computer in this case) know the unique reference number. Thus each voter can assure himself that his vote has finished in the correct count. Secure counting can be done with separate authenticated programs and computers. There exist a number of precautions to take, but these are known to many people.

Remote voting If ballot papers can be sent securely to the recipients, then it is easy for a computer to arrange that the random candidate permutation is different for each ballot paper or is uniformly distributed among the ballot papers. The list of contents of the boxes on the paper, together with the voter identification number, is returned as the vote. This also prevents alphabetical bias in the voting. Li Gong has pointed out that if the identification number is wrong, it is possible to arrange the printing and response such that the vote has been apparently cast but does not contribute to the totals. Thus the buyer of a vote has no guarantee of his purchase, so that postal or online voting can be made about as secure as a voting booth.

Multiple Alternative Voting

309

Counting methods If done by computer, there is little point in shortcuts, and a simple MAV program can be verified and checked much more easily than an STV program. If the number of votes is small, say less than 100, the work is relatively simple and quick. Where the number of votes is large and manual methods are used, then repeated scanning can be almost eliminated by having (C + 1)V separate piles during the first scan. Each pile corresponds to one possible sequence of the first V preferences. Then only the rejected candidates’ piles need to be referred to again. Where C is large, this process can be modified easily. For example, if some candidates are likely to attract few votes, their piles can be combined. Compared with the counting required for STV, the counting at the first stage for MAV is more onerous, as V times as many votes are handled. However, the subsequent counting movements are likely to be fewer. If all the intermediate sums are not printed, then some further shortcuts are possible. For example, when the low counts cannot affect the result, there is no point in transferring them.

Reference 1

MERCURI, R., ‘A better ballot box,’ IEEE Spectrum, October 2002, pp. 46–50.


45 The Semiotics of Umbrellas

John Wilkes It’s always more fun to tilt at an appropriately sized windmill—and agreeing on which windmill to tilt at often makes the difference between success and failure in research. What I offer here is a humble suggestion for some vocabulary with which to discuss windmill tilting, in the hope that the endeavor will be more productive for all concerned if the beast can better be identified, named, and communicated about. Once upon a time, I found myself engaged in a discussion with a colleague on the relative merits of prototyping a piece of software. That conversation proved unfruitful: as we later discovered, we had very different ideas about what was meant by the term “prototype”. One of us was convinced that the only prototype of value would have to be a first-cut of the software that could be shipped as a product, after some engineering had been “applied” to it. The other was equally adamant that prototypes were merely vehicles to get across an idea—a way to sell a proposal, and perhaps either to demonstrate that it did something useful, or to determine if it did. We parted company, each mystified at the other’s intransigence. Some time later, having become older, if not wiser, I and a new team of people that I was privileged to work with decided that this was all simply a confusion over vocabulary, and that banning the “p-word” would serve us all well. Indeed it has, but we never really found a satisfactory replacement for it that we could remember from one day to the next. Then, a couple of years ago, something clicked after one of those interminable discussions about “what should we do next”. The images shown here emerged (a little soggy) the following morning during my shower. Just for fun, I’ve reproduced my first scribbles of them— illegibilities and all, together with their definitions, and a few related thoughts.

Research nugget: a coherent unit of research work, and typically the result of a

312

J. Wilkes

small(ish) research project; maybe as little as a person-month’s work, maybe as much as a dozen or so. Often achievable by a person or three. Good ones can result in nice technical papers. Connotations of gold mining are not unintentional.

Testbed: a vehicle for obtaining research results as rapidly and efficiently as possible. The purpose of a testbed is to develop, nurture, and support one or more research nuggets—nothing more. Although a testbed may be (too often is) pressed into service in other roles, such as showing off the research work, this mixing of purposes is best viewed for what it is: a distraction. The evaluation criterion for a testbed is the ease with which research can be performed. (To help get this across, in a UNIX-centric culture, we used to say, “If MS-DOS works better, use it!”) Vision: a description of some goal, a result that a project is trying to achieve: an “end state” in the consultant’s jargon. I’ve found it helpful to separate out the vision from the research. The research (at least in my world) is best thought of as supporting or enabling a vision. Indeed, it often comes about by working backwards: “What in that vision can’t we do today?” Visions are helpful in justifying work: explaining “what it all means” and why we want to go there. Good visions seem to be contentious and attractive; bad ones vacuous, or simply dull. Visions are good vehicles for teasing out subjective notions of “value” from possible participants in, or customers of, a piece of work: if a vision doesn’t catch people’s imagination, the work to achieve it is unlikely to be pursued with enthusiasm. It’s usually helpful if there is a common vision, since that means people who subscribe to it agree on the goal. But associated with the one larger vision, it’s also common to have multiple, smaller-scale or smaller-scope visions. Ideally (!) the smaller visions complement one another, and can be seen as contributing to the bigger one.

Showcase: a tool used to demonstrate some or all of (1) a vision, (2) research work, and/or (3) that a team is making progress. A showcase that’s an executable piece of code is sometimes called a demonstrator. Other forms include published

The Semiotics of Umbrellas

313

papers, mocked-up user interfaces, storyboards, and presentations (preferably with attractive animations) claiming magnificent things.

The test for a good showcase is that it makes visible what the excitement is all about and focuses attention on the accomplishments, rather than on the effort required to achieve them. Unfortunately, this seems to mean that it’s quite hard to build good showcases for operating systems, middleware, or anything that hides or reduces work. In some cases, a testbed may be usable in (or even as) a showcase. But these two roles are different, and suggestions to “economize” in this form should usually be treated with skepticism: it’s all too easy to end up with an unconvincing showcase that is inconvenient to do research in. Most research nuggets can fruitfully fit into one or more showcases. Indeed, it’s often a useful idea to think through how the research will be demonstrated before too much effort is put into doing it! Showcases can readily complement one another: a larger vision may best be described and demonstrated in pieces, especially early on, although it’s often helpful if there’s a “core” showcase being aimed for, and some of my colleagues have reported that mocking up such a showcase is often all that it takes to sell a key idea.

Umbrella projects: a grouping or coalescing “wrapper” that ties together a set of other activities into a common theme. Like the p-word, the “umbrella” concept often seems to cause confusion. Indeed, I’ve heard it used to describe a vision, a single large project, and a politically correct shield for continuing business as usual (especially after inputs of the form “It is now a corporate mandate that all projects must …”). More useful, perhaps, are the relatively benign forms described here. Flying in formation: Here, there is a set of research nuggets that share a common vision, but the ties between the pieces of work that go into the nuggets are relatively weak, and it’s unlikely that a single, coherent showcase can be put together.

314

J. Wilkes

Compared to the next alternative, the lack of a single showcase can greatly reduce the amount of integration work required, but it still may be possible to spin (sorry: present) all the research as conforming to a single coherent vision. A unifying showcase: this is closer to the “single large project” model. A single showcase is used to tie together the individual pieces of research and demonstrate them and their inter-relationships. A unifying showcase is usually significantly more work to get set up— especially for the first few nuggets—but can present a correspondingly more compelling façade. In my experience, getting one of these unifying showcases agreed to is a black art. It requires somebody to have the courage of their convictions (and a silver tongue) to persuade others of the viability, utility, and excitement of the associated vision. It can be done. I wish it were done more often. The (slightly) greater ability to pull this off is one of the few distinguishing factors associated with a top-notch industrial research establishment, as compared to an academic one. If effective, such a unifying showcase has the advantage of achieving higher impact than a single research nugget can manage by itself. The obvious disadvantages are the relatively high risk (“What if we pick the wrong problem?”), exacerbated by the fear of putting too many eggs in one basket; the difficulty of reaching a common understanding of the goal (“What about this other interesting side issue?”); and the potentially high integration cost of the showcase artifact, which now becomes more of an industrial-strength vehicle than a research tool per se. In practice, of course, nothing is as simple as this exposition suggests, as the (deliberately rather muddled) diagram to the left attempts to illustrate. Real-life projects mix and match approaches and techniques, in response to all sorts of outside and internal pressures, requests, and ideas. Research nuggets, testbeds, and showcases come and go—or morph into new ones as understanding, interest, and opportunity allow.

The Semiotics of Umbrellas

315

Most projects end up with a mixed bag of assorted testbeds, supporting a set of research nuggets that contribute to different showcases at different times. But good projects seem to retain at least a thread of a common vision—even if parts of it may be submerged temporarily and new elements appear. I’ve found that attempting to tease out the different roles and assumptions of each piece is still a beneficial activity. Recursion is often useful in this exercise: what looks to be a research nugget (or vision, etc.) can often be sub-divided, and the same analysis applied to each piece. Over the past couple of years, these ideas have seemed to resonate with my colleagues, and they have proven useful as a way to communicate ideas for structuring and focusing some of our work. One day, perhaps, they might help us approach the scale of effects and impact achieved by the apparently effortless, laissez faire project-management processes that the Computer Laboratory used in the heyday of the Cambridge Distributed System. We can but dream.


46 Computers for Specialized Application Areas

Maurice Wilkes

With the end of CMOS looming ahead—although there is still a significant way to go—it is natural that people should begin to search for innovative computing devices that would be very fast on certain specific problems, even if they were not capable of running a general work load. The economic viability of these devices would depend on finding what is known as a “killer” application, that is, an application of such importance that it would by itself justify the financial investment. The first of these approaches that I heard about was DNA computing. In nature, a DNA molecule has the role of storing genetic information. However, there is no reason way an artificially synthesised DNA molecule should not be used to represent information of a very different kind. In spite of long continued effort, it was not found possible to identify a killer application, and in consequence, DNA computing has dropped out of the picture as far as high-performance computing is concerned. Quantum computing is now attracting great interest. A form of universality can be claimed for a quantum computer, but this is a theoretical claim only. Only applications that could efficiently exploit the special quantum features would run at super-speed. Others would run at a snail’s pace. A quantum computer would not, therefore, be capable of running a general workload in the way that a PC or a workstation can. For this reason, I am inclined to think that the old-fashioned (analogue) computers, such as the differential analyser, provide a better operational model for quantum computing than the modern PC or workstation does. The principal application being talked about as a killer application for a quantum computer is the factorisation of large numbers, an operation of importance in code breaking. However, there may be others. The physics behind the quantum computer is in the early stages of development, and the practical problems of making a working quantum computer have hardly been explored. In spite of the great public interest that has been aroused, it is clear to me that practical applications in the computer field are so far away that developments should be left for the time being exclusively in the hands of

318

M. Wilkes

the physicists. It is hard to see any present justification for the computer industry investing more than token sums in quantum computing. However, it is interesting to speculate on what would happen if a quantum computer that would enable very large numbers to be factorised easily were ever developed. This is a subject on which I would much like to have heard Roger Needham’s views. The use of encryption algorithms, based on numbers that are hard to factorise, has become so pervasive throughout the computer field that an “industry” may be said to have grown up around it. Would the effect of the quantum computer be to destabilize that industry, with widespread repercussions? What alternative means of encryption could be used instead? In my view, it is through its impact on computer security that quantum computing, if it ever comes, might have a major impact on the computing world. Even if other killer applications were to emerge and were to become of great importance in their respective specialized areas, they would be of small importance for the computer field as a whole.

Computer Security?

The Royal Society Clifford Paterson Lecture, 2002 Roger Needham1

Abstract The technical aspects of computer security have fascinated researchers (including the author) for decades. It is, however, beginning to appear that the challenging problems are to do with people, rather than with mathematics or electronics.

Historical development Computer security as a topic is about forty years old. Before then computers were used sequentially by different users, each user being presented with a tabula rasa which was restored at the end of the user’s session. Computers did not, in general, maintain on-line state in the form of files and other forms of persistent data over long periods for many users. When this changed security became an issue. Who or what could legitimately access particular files? How could one be sure that the actions of a program running on behalf of one user did not alter or corrupt the behaviour of another user’s program? Could a malicious user subvert the entire system so that it did nothing useful for anyone? How did we know that a user was who he purported to be? These were burning system design questions in the 1960s and into the 1970s. Characteristically one was talking about a single computer with many users. It was accordingly possible to incorporate protection mechanisms into the hardware design of the machine, and to arrange that while a particular user’s program was running the hardware could be so set up as to make it physically impossible for unauthorized access from the user’s program to other programs and data to

1

This was Roger’s last public lecture, given on 14th November 2002. It was published in the Philosophical Transactions of the Royal Society, Series A, vol. 361, 2003, pp. 1549–1555. The editors are grateful to the Royal Society for permission to reproduce this paper.

320

Needham

occur. Nevertheless the systems of that time were in fact not very secure. When calls were made by a user program to the operating system the arguments presented to them often needed validation, but either the validation software was incorrect, or, more insidiously, it proved possible to change the value of an argument after it had been checked but before it was used. At about the time when single system security was such that one could say with the classically cynical American engineer “That’s good enough for Government work” the rules suddenly changed. The invention of local area and wide area networks in the 1970s meant that related computations did not always happen in the same machine or might be spread over several machines. It was no longer possible to use physical means to prevent unauthorized access, since data passed from one place to another on a typically broadcast medium to which numerous other machines were attached. The exposed nature of communication paths made it much harder to pass data designed to authenticate an individual, such as a password. By one of those coincidences that sometimes solves big problems, at the crucial time cryptographic algorithms became generally available. Earlier cryptography had been an arcane subject practiced by people you didn’t want to know about; suddenly, and not entirely to the pleasure of governments, it became a widely practiced and fascinating research topic. By the late 1970s cryptographic techniques were sufficiently well established that it was possible to pass data across a network from A to B in such a way that nobody but B could understand it, and such that if it had been altered in any way B would know; all this without A and B sharing a secret. Additionally these developments gave rise to a wave of new activity in the area that borders between computer science and mathematics; a wave that continues to this day. One can distinguish two strands in this activity. One, in which I have myself worked quite a lot, is to do with protocols for carrying out, in distributed systems, such tasks as user authentication, non-repudiable transactions, program certification, and so on; in general to use known cryptographic techniques correctly. Protocols of this sort are extremely easy to get wrong in subtle ways, and this fact has given rise to a secondary industry of formal methods for exploring protocol correctness. I was lucky enough to be in at the beginning of both these activities. The other major strand derives from the mathematics of public key cryptography and the believed difficulty of factoring very large numbers and working out some discrete logarithms. People of a much more mathematical turn than I have become extraordinarily agile in putting together algorithms that seem to have security relevance. Why do I say “seem to”? Because in essence what is going on is that we have a set of conditions for some action to be proper, and the mathematics is used to model a test for those conditions. The model may not always be exact. Not only in security is it the case that an ordinary person has a problem and a friendly mathematician solves a neighbouring problem. An example that is of interest here is the electronic book. We have a pretty good idea of the semantics of the paper book. We go and buy it, we can lend it to our spouse or to a friend, we can sell it, we can legitimately copy small bits of it for our own

Computer Security?

321

use, and so on. The electronic book is different. It is a device that we own and is convenient for reading text on (whether such things really exist is a different issue). We pay for the digital representation of a book and download it into our device. The publisher of the book has a legitimate interest in the preservation of his intellectual property, and enlists the services of good mathematicians and system designers to make measures to do so. Unfortunately these measures do not have the same semantics as the paper book. I may not be able to lend the electronic book to my spouse without lending her the device even if she has one of her own. I may not be able to copy even small bits of it. The technical solution has not matched the real world need. Despite all the theoretical progress that has been made, and the very ingenious papers that have been published, systems remain rather insecure. This is not primarily because of bad algorithms or protocols. It is to a substantial extent because of ignoring the human element. Even in the mechanical aspects just outlined, the human element is sometimes crucial. An example is non-repudiation, where the purpose of a protocol is to furnish evidence that will convince an arbitrator that a party attempting to repudiate a transaction did in fact commit to it. The arbitrator is, and has to be, human. People figure in security in a variety of ways. They may be the users of a system, who need protecting from each other and from whom the system itself needs to be protected. They may be the people who set up security systems; they may be the people who specify lists of access permissions, they may be local security administrators. We shall see how crucial all these people are.

Secrets All the techniques for authentication depend on the physical inaccessibility of something. People cannot remember elaborate encryption keys, or the codes that characterize their irises, for example. These have to be stored in some object, and the integrity of authentication depends on the integrity of this object. Many objects are quite unsuitable for keeping serious material that should not be disclosed or altered. In particular PCs are unsuitable, and are getting more so as it becomes more usual for home PCs to be connected to the internet all the time. Smart cards are sometimes said be a panacea, with almost magical virtues. But they aren’t all that secure, and their contents often get to be used outside the card, where their security is at best problematic. In general it is extremely awkward to run secure systems, and real people typically will not. This was cited, in a recent public debate in the UK, as a reason for it being unnecessary for the Government to take to itself the draconian powers it has to require production of decryption keys in various circumstances. It was said that what the Government needed was a Royal Corps of Hackers, not vast legal powers.

322

Needham

Policies The security policies of organizations are vast, informal, and incomprehensible. There is no proper notation for saying what the policies are exactly, and they grow up over time. The source of the policies is sometimes what is seen as ‘common sense’ and sometimes the end effect of legal requirements. As an example of the latter, a corporation has to pay attention to the security of trade secret material because, in the event that some such material is misappropriated, it would be a valid defence in Anglo-Saxon law for the appropriators to say that nothing wrong had happened since the corporation didn’t seem to care much anyway. Another instance is the prohibition of certain employees from dealing in a corporation’s shares during the period in advance of the announcement of quarterly results. For this prohibition to be effective the results must be kept to as few employees as possible as they are prepared. Then there are policies that come from prudence. In companies that make computers it is, or at any rate was, customary to go to great lengths to conceal future developments from the sales and marketing people. This apparently paradoxical approach was so that the sales folk would not sell things that did not yet exist, generating embarrassment at best and antitrust problems at worst. If you’re a manager in Microsoft you have access to salary, bonus, and performance details for those who report through you, but not for those to whom you report (nor, incidentally, yourself). When I was Head of the University Computer Laboratory I signed all purchase orders except that when I was away someone else did, provided that the deputy hadn’t raised the order in which case a second deputy was used for separation of duty reasons. I have given these examples as a miscellaneous collection to show what organizational security policies are really like. In enforcing them we depend on far more than knowing who somebody is. An immediate question is whether, as transactions become steadily more electronic, these rules and practices should be technically enforced or organizationally enforced, as they often are in the paper world. I get the impression that because it is possible to imagine the enforcement being technical then that is often regarded as the ideal goal, and that security engineers should go as far in that direction as they can. In this context I can tell a cautionary tale. In the late 1970s a corporate research lab was experimenting with the ‘paperless office’. They devised a system in which documents that looked on screen like well-known company forms such as purchase orders, payment authorizations, expense reports and so forth were passed from one screen to another for successive steps of authorization. Naturally when a manager had signed off on a part of the form subsequent signers could not alter it. This appeared to the researchers to be an obvious requirement. When the system was complete it was tried out in an actual corporate office of the same company. It produced real chaos; almost rigor mortis. In real life forms were altered after signature all the time for entirely good reasons. In the Computer Laboratory, the probability that purchase orders were altered after my signature was not all that

Computer Security?

323

high, but it happened often enough that it would be a real pain for me to have to re-sign orders that had been changed from 2000 No. 8 screws to 2000 No. 10 screws, or where a part number had been corrected because the sender noticed it was wrong while putting the order in the envelope. If we look at my earlier security example, namely backup for me in signing orders, we can glean useful insights. Suppose an order for 10,000 pounds (quite large by the standards of a University Department) had been taken to my first reserve for signature. He would quite probably know whether I was there or not. If not, and if the order was handed to him personally, he would ask the hander whether he’d looked for me. If the order just turned up in his in-tray he would phone my secretary and ask if I was around. If it was a really large order, say for 100,000 pounds, and I had gone to London for the morning to be back by 1500 hours, which fact my secretary would be able to tell him, he would wait. If I was away for a week he probably would not. To enforce all that electronically would be a Big Deal. The reserve would of course have to be authenticated, as would the identity of whoever sent him the order. He would need validated access to my whereabouts and travel plans. Maybe some threshold numbers would have to be incorporated in the program used. When pursuing this sort of line it is very easy to finish up with a requirement to validate an instance of a whole operating system. Indeed, this point is reached very quickly when one tries to protect intellectual property in material to be displayed in an ordinary PC. My purpose in going into all this is to stress that the more we mechanically enforce rules of ordinary business practice the more metadata we generate, in terms of rules of behaviour, methods of validating data of all sorts, in addition to access control lists, role tables, security libraries, and all the rest of the clutter.

Metadata: the data that describes the data In a complex set-up, for example a large corporation, someone will ask the question ‘Does the ensemble of rules and other metadata actually give effect to the security policy?’ A proper interpretation of this would require not only that those actions forbidden by the policy cannot be done but that actions not forbidden by the policy can be done. This soon becomes formidably difficult, and for some access control systems can be mathematically undecidable. Such situations are prone to bizarre errors, as in a case I heard of where the proprietors of a large data system were very proud of their access controls, based on an elaborate security library. It was only as part of an outside investigation that it was noticed that the security library itself was open to write access by anyone! One is strongly pressed to the conclusion that if something can sensibly be enforced by human means it very probably should. Even deciding this is difficult. Essentially human enforcement relies on integrity of people; it is more reasonable to rely on the individual integrity of six senior people in the finance division who are paid a lot

324

Needham

than on the individual integrity of five thousand counter clerks who are paid a little. If we contemplate this conclusion, heretical as it is for a computerist, we can see other good reasons for it. Error in handling metadata is at least as likely to forbid necessary actions as to permit unwanted ones. It is not unusual for a new employee not to be able to do his or her job properly for several weeks because permissions have not been set up. It has happened that the administration of my research lab came to a halt because of an erroneous change to access controls in Redmond, Washington, eight time zones away. Of course when we noticed the problem the person responsible was asleep in bed, and we just had to wait until the next day. This does not matter too much for a research lab, but it would be very damaging for a supermarket or a stockbroker. An extreme case is a military one, where more and more use of computers and data is being made in support of deployed operations. You can’t stop a battle while access controls are fixed. All our experience is that things that should not or even logically cannot happen sometimes do happen, and the more complex the web of technical restraints the more difficult it is likely to be to recover effectively. To illustrate very simply the importance of recovery issues, there is a well-known attack on the Needham-Schroeder authentication protocol [1]. The attack depends on something happening that in the proper course of the protocol should not be able to happen; but the seriousness of the attack comes from the fact that there is no way to recover at all when it has happened. The recovery issue is a very serious one, and compounds the complexity discussed at length above. It is really hard to catalogue, and to find out how to recover from, the things that should not happen but will. If organizational authority can over-ride protocol, then recovery can occur by use of human ingenuity. For example a high-ranking officer can say ‘Fire the goddam thing anyway!’

Logging If we follow this line of thought we can go further. This is where it matters that we are talking about security within an organisation rather than in the world in general. In an organisation there are more ties among the individuals than there are in the outside world; for example soldiers are subject to military discipline, and there is an assumption that employees in general do not want to get fired. To some extent we can exploit this to simplify security matters. Keeping a record of what has been done can be a simple solution to otherwise difficult problems. Here’s an example. Anyone can buy a copy of my bank statement from a dubious enquiry agent for some 200 pounds. This is because any teller in the employ of my bank can ask for it, and since the bank is a large one there are enough tellers over all branches that some will be willing to earn a little money on the side. Yet having all the tellers able to have access is in other ways a good thing. The security would be much improved if the act of generating a copy of a statement were

Computer Security?

325

recorded in the statement itself, so that when I got my regular monthly printout I could see that a statement was asked for by teller number 3 in the Penzance branch, and I could raise a complaint if I was in Philadelphia at the relevant time. It is not clear to me why banks do not do this, but that is another question. It is worth noting that maintaining logs is often rejected as a security technique on the bogus argument that there is too much log material for anyone to look at. The present case is an example where parallel processing at the level of millions makes light of the volume of stuff. After all, most of us give our bank statements at least a cursory scan.

People To compound the effects of complexity, humans involved in managing security are fallible, lazy, and uncomprehending. The first applies to all of us, but the other two may seem surprising. I shall now try to explain why they are mentioned here. Security is a nuisance. It gets in the way, in the manner that a locked door gets in the way even if you have a key to it. Even if you have brought the key with you the door is an obstruction, and is even more so if you have to go back to wherever you left the key. A local security officer has the duty of making sure that the features that make for inconvenience are in place and effective. The life of a local security administrator is much easier, and the administrator much less unpopular with colleagues, if the administrator’s job is not done ‘properly’. The incentives on the security administrator are thus not very appropriate. I am credibly advised that units in the armed services are particularly adept at simplifying their lives in this sort of way but so are bank branch managers, hospital administrators, and so forth. Wherever there are devolved units that have a certain amount of discretion in the management of their internal affairs, burdensome security will be circumvented. As much damage cane be done because people are uncomprehending. A well-known story describes two senior bank managers being sent two parts of a cryptographic key to load into a security module. They were sufficiently senior that they didn’t care to use keyboards, so they gave the two pieces of paper to the same technician to enter, thus losing the entire purpose of the two parts. They didn’t understand why it was supposed to be done the way it was supposed to be done. Another tale, not directly connected with security, concerns a distributed and devolved naming service, that replicated data widely for easy access. For such a system to work it is clearly necessary to have a lot of discipline about the processes of installing new instances so that update messages can be sent to the required places. Local managers simply didn’t understand all this, and if one of their instances misbehaved they would simply shoot it and make a new one. Update messages would be directed to the instance that no longer existed, and would be returned undelivered. They would not be delivered to the new instance

326

Needham

which soon stopped being current. Confusion reigned. These examples show the results of overestimating the understanding and probably even the intelligence of the local agents. The system was designed by very well educated and well informed people who simply did not think of the contrast between themselves and the people on the ground.

An agenda for research The conclusion I draw from this in some ways depressing tale is that there is a great scope for research in a number of areas. First, can we find means of expressing security policies such that machine aids may be used to help check whether available technical measures are capable of implementing the policies? It may be impossible, but it would be nice to know. Note that I said ‘machine aids.’ Researchers working on theorem proving spent a lot of time trying to get fully automatic proof engines, and eventually realised that machine aided proof was much more effective. Second, can we find tools to assist in auditing security data to check for policy compliance? Third, can we find means to express local operating rules so that their rationale is apparent to local operations people, who might therefore take them more seriously? Alternatively, can we find ways to simplify the task of local security administrators so that there is less encouragement for circumvention? These issues are partly technical and partly managerial. It is greatly to be hoped that the managerial content does not deter computing researchers from tackling them, for their importance is great. Computing researchers need to climb down from their ivory towers to look at the real world contexts in which their systems will be deployed.

Reference 1.

NEEDHAM, R.M., AND SCHROEDER, M.D., ‘Using encryption for authentication in large networks of computers,’ Comm. ACM, vol. 21, no. 12, 1978, pp. 993–999.

Roger Needham: Publications

Compiled by Karen Spärck Jones

With T. Joyce: ‘The thesaurus approach to information retrieval,’ American Documentation, 9 (3), 1958, 192–197; reprinted in Readings in information retrieval, ed. K. Spärck Jones and P. Willett, San Francisco, CA: Morgan Kaufmann, 1997. With M. Masterman and K. Spärck Jones: ‘The analogy between mechanical translation and library retrieval,’ Proceedings of the International Conference on Scientific Information (1958), National Academy of Sciences—National Research Council, Washington, DC, 1959, vol. 2, 917–935. With A.F. Parker-Rhodes: ‘A reduction method for non-arithmetic data, and its application to thesauric translation,’ Information Processing: Proceedings of the International Conference on Information Processing (1959), Paris, 1960, 321–327. With A.F. Parker-Rhodes: ‘The theory of clumps,’ Cambridge Language Research Unit, Report M.L. 126, 1960. With A.H.J. Miller and K. Spärck Jones: ‘The information retrieval system of the Cambridge Language Research Unit,’ Cambridge Language Research Unit, Report M.L. 109, 1960. ‘The theory of clumps II,’ Cambridge Language Research Unit, Report M.L. 139, 1961. Research on information retrieval, classification and grouping 1957–1961, Ph.D. thesis, University of Cambridge; Cambridge Language Research Unit, Report M.L. 149, 1961. ‘A method for using computers in information classification,’ Information Processing 62: Proceedings of IFIP Congress 1962, ed. C. Popplewell, Amsterdam: North-Holland, 1963, 284–287.

328


‘Automatic classification for information retrieval,’ in Information retrieval, ed. Serbanescu, I.B.M. European Education Centre, Blaricum, Holland, 1963. ‘Automatic classification for information retrieval,’ lectures given at the NATO Advanced Study Institute on Automatic Document Analysis, Venice, 1963; abstracts published as Cambridge Language Research Unit Report M.L. 166, 1963. ‘The exploitation of redundancy in programs,’ in The Impact of Users’ Needs on the Design of Data Processing Systems, Conference Proceedings, United Kingdom Automation Council, 1964, 6–7. With K. Spärck Jones: ‘Keywords and clumps,’ Journal of Documentation, 20 (1), 1964, 5–15. ‘Information retrieval,’ Computing science, Report to the Science Research Council, ed. D. Michie, 1965, 92–94. ‘Automatic classification—models and problems,’ in Mathematics and computer science in biology and medicine, London: Medical Research Council, 1965, 111–114. ‘Computer methods for classification and grouping,’ in The use of computers in anthropology, ed. D. Hymes, The Hague: Mouton, 1965, 345–356. ‘Applications of the theory of clumps,’ Mechanical Translation, 8 (3/4), 1965, 113–127. ‘Semantic problems of machine translation,’ Information Processing 65: Proceedings of IFIP Congress 1965, ed. W. Kalenich, Washington DC: Spartan Books, 1965, vol. 1, 65–69. ‘Information retrieval and some cognate computing problems,’ in Advances in programming and non-numerical computation, ed. L. Fox, London: Pergamon Press, 1966, 201–218. ‘The termination of certain iterative processes,’ Rand Corporation, Santa Monica, Report RM-5188-PR, 1966. ‘Automatic classification in linguistics,’ The Statistician, 17 (1), 1967, 45–54. With D.W. Barron, A.G. Fraser, D.F. Hartley, and B. Landy: ‘File handling at Cambridge University,’ Proceedings of the 1967 Spring Joint Computer Conference, AFIPS Conference Proceedings, vol. 30, 1967, 163–167.


329

With K. Spärck Jones: ‘Automatic term classifications and retrieval,’ Information Storage and Retrieval, 4 (2), 1968, 91–100. With M.V. Wilkes: ‘The design of multiple-access computer systems: part 2,’ Computer Journal, 10, 1968, 315–320. With D.F. Hartley and B. Landy: ‘The structure of a multiprogramming supervisor,’ Computer Journal, 11, 1968, 247–255. ‘Consoles in the cloisters,’ Datamation, January 1969. With D.F. Hartley: ‘Operational experience with the Cambridge multiple-access system,’ Computer Science and Technology, Conference Publication 55, Institution of Electrical Engineers, London, 1969, 255–260. ‘Computer operating systems,’ in Encyclopedia of linguistics, computation and control, ed. A.R. Meetham and R.A. Hudson, London: Pergamon Press, 1969, 57–58. With D.F. Hartley: ‘Theory and practice in operating system design,’ 2nd ACM Symposium on Operating System Principles, Princeton, 1969, New York: ACM, 1969, 8–12. ‘Software engineering techniques and operating system design and production’ and, with D. Aron, ‘Software engineering and computer science,’ in Software engineering techniques, ed. J. Buxton and B. Randell, NATO Scientific Affairs Committee, NATO, Brussels, 1970, 111–113 and 113–114. ‘Handling difficult faults in operating systems,’ 3rd ACM Symposium on Operating System Principles, Stanford, 1971, New York: ACM, 1971, 55–57. With B. Landy: ‘Software engineering techniques used in the development of the Cambridge multiple access system,’ Software—Practice and Experience, 1 (2), 1971, 167– 173. ‘Tuning the Titan operating system,’ in Operating systems techniques, ed. C.A.R. Hoare and R. Perrott, London: Academic Press, 1972, 277–281. ‘Protection systems and protection implementations,’ Proceedings of the 1972 Fall Joint Computer Conference, AFIPS Conference Proceedings, vol. 41, 1972,

330


571–578; reprinted in The Auerbach Annual, 1972—Best Computer Papers, ed. I.L. Auerbach, Philadelphia, PA: Auerbach (?), 1972. ‘Protection—a current research area in operating systems,’ Proceedings of the International Computing Symposium 1973, ed. G. Gunter, B. Levrat, and H. Lipps, Amsterdam: North-Holland, 1974, 123–126. With M.V. Wilkes: ‘Domains of protection and the management of processes,’ Computer Journal, 17 (2), 1974, 117–120; reprinted in The Auerbach Annual, 1975—Best Computer Papers, ed. I.L. Auerbach, New York: Petrocelli/Charter, 1975; reprinted in Japanese, 1976. With R.D.H. Walker: ‘Protection and process management in the CAP computer,’ Proceedings of the International Workshop on Protection in Operating Systems, IRIA, Paris, 1974, 155–160. ‘The future of central computing services,’ Proceedings of the 1976 Computing Services Management Conference, ed. D.H. McClain, Inter University Computing Committee, 1976, 74–76. Articles in Encyclopedia of computer science, ed. A. Ralston and C. Meek, New York: Petrocelli/Charter 1976. ‘The CAP project—an interim evaluation’ (6th ACM Symposium on Operating System Principles, 1977), Operating Systems Review, 11 (5), 1978, 17–22. With R.D.H. Walker: ‘The Cambridge CAP computer and its protection system’ (6th ACM Symposium on Computer Operating System Principles, 1977), Operating Systems Review, 11 (5), 1978, 1–10. With A.D. Birrell: ‘The CAP filing system’ (6th ACM Symposium on Computer Operating System Principles, 1977), Operating Systems Review, 11 (5), 1978, 11–16. With M.D. Schroeder: ‘Using encryption for authentication in large networks of computers,’ Xerox Palo Alto Research Centre, Report CSL-78-4, 1978; Communications of the ACM, 21 (12), 1978, 993–999; reprinted in Advances in computer security, ed. R. Turn, Dedham, MA: Artech House, 1988.


331

With A.D. Birrell: ‘An asynchronous garbage collector for the CAP filing system,’ Operating Systems Review, 12 (2), 1978, 31–33. With A.D. Birrell: ‘Character streams,’ Operating Systems Review, 12 (3), 1978, 29–31. With H.C. Lauer: ‘On the duality of operating system structures’ (Second International Conference on Operating Systems, 1978), Operating systems: theory and practice, ed. D. Lanciaux, Amsterdam: North-Holland, 1979, 371–384; reprinted in Operating Systems Review, 13 (2), 1979, 3–19. ‘Protection’ (Advanced Course on Computing Systems Reliability, Newcastle, 1978); in Computer systems reliability, ed. T. Anderson and B. Randell, Cambridge: Cambridge University Press, 1979, 264–287. ‘Protection—theory and practice,’ Proceedings of the SEAS Anniversary Meeting 1978, vol. 1, 1978, 80–84. With M.V. Wilkes: The CAP computer and its operating system, New York: Elsevier NorthHolland, 1979. ‘Adding capability access to conventional file servers,’ Operating Systems Review, 13 (1), 1979, 3–4. ‘Systems aspects of the Cambridge Ring’ (7th ACM Symposium on Operating System Principles, 1979), Operating Systems Review, 13 (5), 1979, 82–85. With M.V. Wilkes: ‘The Cambridge model distributed system,’ Operating Systems Review, 14 (1), 1980, 21–29. With A.D. Birrell: ‘A universal file server,’ IEEE Transactions on Software Engineering, vol. SE-6 (5), 1980, 450–453. With N.H. Garnett: ‘An asynchronous garbage collector for the Cambridge file server,’ Operating Systems Review, 14 (4), 1980, 36–40. With A.J. Herbert: ‘Sequencing computation steps in a network’ (8th ACM Symposium on Operating System Principles, 1981), Operating Systems Review, 15 (5), 1981, 59–63.

332


‘Design considerations for a processing server,’ Proceedings of the 8th Annual Symposium on Computer Architecture, 1981, IEEE, 501–504. ‘Capabilities and protection’ (Proceedings, GI-10, Saarbrücken, 1980), GI-10. Jahrestagung, ed. R. Wilhelm, Berlin: Springer-Verlag, 1980, 45–53. With A.D. Birrell, R. Levin, and M.D. Schroeder: ‘Grapevine: an exercise in distributed computing’ (presented at the 8th ACM Symposium on Operating Systems Principles, 1981), Communications of the ACM, 25, 1982, 260–274; reprinted in Birrell et al., ‘Grapevine: two papers and a report,’ Xerox Palo Alto Research Centre, Report CSL-83-12, 1983. With A.J. Herbert: The Cambridge distributed computing system, Reading, Mass.: Addison-Wesley, 1982. With M.F. Richardson: ‘The Tripos Filing Machine—a front-end to a file server’ (9th ACM Symposium on Operating Systems Principles, 1983), Operating Systems Review, 17 (5), 1983, 120–128. With A.J. Herbert and J.G. Mitchell: ‘How to connect stable memory to a computer,’ Operating Systems Review 17 (1), 1983, 16. With M.D. Schroeder and A.D. Birrell: ‘Experience with Grapevine: the growth of a distributed system,’ ACM Transactions on Computer Systems, 2 (1), 1984, 3–23; reprinted in Birrell et al. ‘Grapevine: two papers and a report,’ Xerox Palo Alto Research Center, Report CSL83-12, 1983. With I.M. Leslie, J.W. Burren, and G.C. Adams: ‘The architecture of the Universe network’ (SIGCOMM 84 Tutorials and Symposium: Communications Architectures and Protocols), Computer Communications Review, 14 (2), 1984, 2–9. With A.G. Waters, C.G. Adams, and I.M. Leslie: ‘The use of broadcast techniques on the Universe network’ (SIGCOMM 84 Tutorials and Symposium: Communications Architectures and Protocols), Computer Communications Review, 14 (2), 1984, 52–57. ‘Fifth generation computing,’ in Information comes of age, ed. C. Oppenheim, London: Rossendale, 1984, 71–77.


333

‘Protection,’ in Local area networks: an advanced course, ed. D. Hutchison, J. Mariani and D. Shepherd, Lecture Notes in Computer Science 184, Berlin: Springer, 1985, 261–281. With M.D. Schroeder and D.K. Gifford: ‘A caching file system for a programmer’s workstation,’ DEC Systems Research Centre, Palo Alto, Report 6; (10th ACM Symposium on Operating Systems Principles, 1985), Operating Systems Review, 19 (5), 1985, 25–34. ‘Is there anything special about AI?’ (Workshop on the Foundations of Artificial Intelligence, 1986), in The foundations of artificial intelligence: A source book, ed. D. Partridge and Y. Wilks, Cambridge: Cambridge University Press, 1990, 269–273. With A.D. Birrell, B.W. Lampson, and M.D. Schroeder: ‘A global authentication service without global trust,’ Proceedings of the IEEE Symposium on Security and Privacy, 1986, 223–230. With D.L. Tennenhouse, I.M. Leslie, C.A. Adams, J.W. Burren, and C.S. Cooper: ‘Exploiting wideband ISDN: the Unison exchange,’ IEEE INFOCOM Conference Proceedings, San Francisco, 1987, 1018–1026. With M.D. Schroeder: ‘Authentication revisited,’ Operating Systems Review, 21 (1), 1987, 7. ‘The Unison experience,’ Proceedings of the 23rd Annual Convention of the Computer Society of India, ed. S. Raghavan and S. Venkatasubramanian, New Delhi: Macmillan, 1988, 51–57. With D.K. Gifford and M.D. Schroeder: ‘The Cedar file system,’ Communications of the ACM, 31 (3), 1988, 288–298; reprinted, in Japanese, in Bit, November 1989, 30–50. With A. Hopper: ‘The Cambridge fast ring networking system,’ IEEE Transactions on Computers, 37 (10), 1988, 1214–1223. With M. Burrows and M. Abadi: ‘Authentication: a practical study of belief and action,’ Proceedings of the 2nd Conference on Theoretical Aspects of Reasoning about Knowledge, ed. M. Vardi, Los Altos, CA: Morgan Kaufmann, 1988, 325–342.

334


With M. Burrows: ‘Locks in distributed systems—an observation,’ Operating Systems Review 22 (3), 1988, 44. With M. Burrows and M. Abadi: ‘A logic of authentication,’ DEC Systems Research Centre, Palo Alto, Report 39, 1989; Proceedings of the Royal Society of London, Series A, 426, 1989, 233–271; reprinted in Practical cryptography for data internetworks, ed. W. Stallings, Washington DC: IEEE Computer Society Press, 1996. With M. Burrows and M. Abadi: ‘A logic of authentication’ (12th ACM Symposium on Operating System Principles, 1989), Operating Systems Review, 23 (5), 1989, 1–13; and ACM Transactions on Computer Systems, 8 (1), 1990, 18–36. [Refers to the previous Report 39, etc., version as fuller.] With T.M.A. Lomas, L. Gong, and J.H. Saltzer: ‘Reducing risks from poorly chosen keys’ (12th ACM Symposium on Operating System Principles, 1989), Operating Systems Review, 23 (5), 1989, 14–18. ‘Authentication,’ in Safe and secure computing systems, ed. T. Anderson, Oxford: Blackwell Scientific, 1989, 189–196. ‘Names’ and ‘Using cryptography for authentication’ (Arctic 88; Fingerlakes 89: Advanced Courses on Distributed Systems), in Distributed systems, ed. S. Mullender, New York: ACM Press and Addison-Wesley, 1989, 89–101 and 103–116. With J.M. Bacon and I.M. Leslie: ‘Distributed computing with a processor bank,’ Technical Report 168, Computer Laboratory, University of Cambridge, 1989. With M. Burrows and M. Abadi: ‘The scope of a logic of authentication,’ Proceedings of the DIMACS Workshop on Distributed Computing and Cryptography (1989), ed. J. Feigenbaum and M. Merritt, New York: American Mathematical Society, 1991, 119–126. With A. Herbert: ‘Report on the Third European SIGOPS Workshop, “Autonomy or Interdependence in Distributed Systems’,’’ Operating Systems Review, 23 (2), 1989, 3–19. With L. Gong and R. Yahalom: ‘Reasoning about belief in cryptographic protocols,’ Proceedings of the 1990 IEEE Symposium on Security and Privacy, 1990, 234–248.


335

With M. Burrows and M. Abadi: ‘Rejoinder to Nessett,’ Operating Systems Review, 24 (2), 1990, 39–40. ‘Capabilities and security,’ in Security and Persistence: Proceedings of the International Workshop on Computer Architectures to Support Security and Persistence of Information, ed. J. Rosenberg and J. Keedy, Bremen, Germany, 1990, 1–8. With M.D. Schroeder and others: ‘Autonet: a high-speed, self-configuring local area network using point-to-point links,’ DEC Systems Research Centre, Palo Alto, Report 59, 1990; IEEE Journal on Selected Areas in Communications, 9 (8), 1991, 1318–1335. ‘What next? Some speculations,’ in Operating systems of the 90s and beyond, ed. A.I. Karshmer and J. Nehmer, Berlin: Springer Verlag, 1991, 220–222. ‘Later developments at Cambridge: Titan, CAP, and the Cambridge Ring,’ IEEE Annals of the History of Computing, 14 (4), 1992, 57–58. With A. Nakamura: ‘An approach to real-time scheduling—but is it really a problem for multimedia?’ (NOSSDAV 92), in Network and Operating System Support for Digital Audio and Video, ed. P. Venkat Randan, Lecture Notes in Computer Science 712, Berlin: Springer-Verlag, 1992, 32–39. ‘Names’ and ‘Cryptography and secure channels,’ in Distributed systems, ed. S. Mullender, 2nd ed., Reading, MA: Addison-Wesley, 1993, 315–326 and 531– 541. With M.A. Lomas, L. Gong and J.H. Saltzer: ‘Protecting poorly chosen secrets from guessing attacks,’ IEEE Journal on Selected Areas in Communications, 11 (5), 1993, 648–656. Abraham Award for Best Paper in the Journal for 1993. ‘Denial of service,’ Proceedings of the 1st ACM Conference on Communications and Computing Security, 1993, 151–153. ‘Distributed computing,’ Guest Editorial, Computer Bulletin, 6 (2), 1994, 2. With M. Abadi: ‘Prudent engineering practice for cryptographic protocols,’ Proceedings of the 1994 IEEE Symposium on Security and Privacy, 1994, 122–136. Outstanding paper award.

336


‘Computers and communications,’ Computer Science and Informatics (Computer Society of India), 23 (4), 1993, 1–6. ‘Denial of service: an example,’ expanded version of 1993 paper, Communications of the ACM 37 (11), 1994, 42–46. With M. Abadi: ‘Prudent engineering practice for cryptographic protocols,’ expanded version of 1994 IEEE Symposium paper, DEC Systems Research Centre, Palo Alto, Report 125, 1994; IEEE Transactions on Software Engineering, 22 (1), 1996, 6–15. With A. Nakamura: ‘The dependency protocol for real-time synchronisation,’ RTESA 94, Proceedings of the First International Workshop on Real-Time Computing Systems and Applications, IEEE, Seoul, 1994. With D. Wheeler: ‘Two cryptographic notes,’ Technical Report 355, Computer Laboratory, University of Cambridge, 1994. With D.J. Wheeler: ‘TEA, a tiny encryption algorithm,’ Fast Software Encryption, 1994, 363–366. With A. Nakamura: ‘The dependency protocol for real-time synchronisation,’ Transactions of the Institute of Electronic, Information and Communication Engineers, vol. J78-D-I no. 8, 1995, 649–660. With P.W. Jardetsky and C.J. Sreenan: ‘Storage and synchronisation for distributed continuous media,’ Multimedia Systems, 3 (4), 1995, 151–161. With R.J. Anderson: ‘Programming Satan’s computer,’ in Computer science today, ed. J. van Leeuwen, Lecture Notes in Computer Science 1000, Berlin: Springer, 1995, 426–440. With R.J. Anderson: ‘Robustness principles for public key protocols,’ in Advances in cryptology— CRYPTO 95, ed. D. Coppersmith, Lecture Notes in Computer Science 963, Berlin: Springer, 1995, 236–247. ‘Fast communication and slow computers,’ Twelfth International Conference on Computer Communication, Seoul, 1995.


337

‘Computers and communications,’ in Computing tomorrow, ed. I. Wand and R. Milner, Cambridge: Cambridge University Press, 1996, 284–294. ‘The changing environment for security protocols,’ IEEE Network, 11 (3), 1997, 12–15. ‘Logic and oversimplification,’ Proceedings of the Thirteenth Annual IEEE Symposium on Logic in Computer Science, 1998, 2–3. With R.J. Anderson and others: ‘A new family of authentication protocols,’ Operating Systems Review, 32 (4), 1998, 9–20. With R.J. Anderson and A. Shamir: ‘The steganographic file system,’ in Information hiding (Second International Workshop on Information Hiding), ed. D. Aucsmith, Lecture Notes in Computer Science 1525, Berlin: Springer, 1998, 73–84. ‘The changing environment’ (transcript, with discussion), Security Protocols, 7th International Workshop, Cambridge, ed. B. Christianson et al., Lecture Notes in Computer Science 1796, Berlin: Springer, 1999, 1–5. ‘The hardware environment,’ Proceedings of the 1999 IEEE Symposium on Security and Privacy, 1999, 236. Editor, with K. Spärck Jones and G. Gazdar: ‘Computers, language and speech: formal theories and statistical data,’ Philosophical Transactions of the Royal Society of London, Series A, Mathematical, Physical and Engineering Sciences, vol. 358, no. 1769, 2000, 1225–1431. With K. Spärck Jones and G. Gazdar: ‘Introduction: combining formal theories and statistical data in natural language processing,’ ‘Computers, language and speech: formal theories and statistical data,’ Philosophical Transactions of the Royal Society of London, Series A, Mathematical, Physical and Engineering Sciences, vol. 358, no. 1769, 2000, 1225–1238. ‘Distributed computing: opportunity, challenge, or misfortune?’ in Millennial perspectives in computer science (Proceedings of the 1999 Oxford-Microsoft Symposium in honour of Sir Tony Hoare), ed. J. Davies, B. Roscoe, and J. Woodcock, Basingstoke, Hants: Palgrave, 2000, 283–287. ‘Mobile computing versus immobile security’ (transcript), Security Protocols, 9th International Workshop, Cambridge, ed. B. Christianson et al., Lecture Notes in Computer Science 2467, Berlin: Springer, 2001, 1–3.

338


‘Security—a technical problem or a people problem?’ Proceedings, Information Security Summit, Prague: Tate International, 2001, 7–9. ‘Donald Watts Davies CBE,’ Biographical Memoirs of Fellows of the Royal Society, 48, 2002, 87–96. ‘Computer security?’ Philosophical Transactions of the Royal Society, Series A, Mathematical, Physical and Engineering Sciences, 361, 2003, 1549–1555.

Computer Systems: Theory, Technology, and Applications

Computer Systems Theory Technology and Applications

Computer Systems. Theory, Technology and Applications

Theory and Applications of Ontology: Computer Applications

MIMO Systems, Theory and Applications

Grey Systems: Theory and Applications

Cyberspace Textuality: Computer Technology and Literary Theory

Computer-Aided Molecular Design: Theory and Applications

Robust Computer Vision Theory and Applications

Computer-Aided Molecular Design: Theory and Applications

Robust computer vision: theory and applications

Computer Science Research and Technology, Vol. 2 (Computer Science, Technology and Applications)

Monotone Random Systems: Theory and Applications

Fuzzy systems theory and its applications

Monotone Random Systems Theory and Applications

Dynamical Systems: Stability Theory and Applications

Networked Control Systems: Theory and Applications

Optimization of elliptic systems: theory and applications

Piecewise-smooth dynamical systems: theory and applications

Random Dynamical Systems: Theory and Applications

Dynamical Systems: Stability Theory and Applications

Dynamics of information systems : theory and applications

Piecewise-Smooth Dynamical Systems: Theory and Applications

Monotone random systems: theory and applications

Networked Control Systems: Theory and Applications

Dynamical Systems, Ergodic Theory and Applications

Dynamical systems, ergodic theory and applications

Computer vision and applications

Computer vision and applications

Technology Systems and Management

Computer algebra handbook : foundations, applications, systems

Computer Systems: Theory, Technology, and Applications