Catálogo de publicaciones - libros

I’d like to shift views a little bit, and think about the problem that we usually focus on, which is building good defences, from the point of view of how to attack effectively. We tend to focus on the defending problem, for example, the confidentiality of my traffic, and in the mainstream and conservative approach to security that we all know and love we make very generous assumptions about the adversary: we are willing to assume that the adversary gets a copy of every packet we send, it can alter some of the bits in real time, and has unlimited computational power, etc. As a result of that conservative assumption, we ask to have solutions that assume that the network is unlimitedly hostile. And, if you want security, we must accept nothing less than end-to-end security, and if we don’t have to end-to-end security we simply assume that it is insecure, because it would be very silly to depend on anything less than this very reasonable conservative assumption.

We continue the popular theme of offline security by considering how computer security might be applied to the challenges presented in running a secret society. We discuss membership testing problems and solutions, set in the context of security authentication protocols, and present new building blocks which could be used to generate secret society protocols more robustly and generically, including the and the model.

Good afternoon everyone, I was expecting to have the last talk before dinner. [Laughter]. We’re going to take a slightly less serious look at some of the work that George Danezis and myself have been doing on trying to find exciting, or at least interesting, new ways to think about security protocols, and to find environments that encourage us to find interesting new protocols. Our chosen environment is Secret Societies, and although there are all sorts of things in there, we’re going to concentrate mainly on membership testing, and look at some of the algorithms that you might use to figure out whether or not somebody is a member of your secret society, or try and decode whether or not members elsewhere are members of their societies. Then we’ll go on to figure out if we can take what we know from what we read in books, and stories, and history, and do it a bit better using our skills from cryptography, and we’ll look at a couple of models that we have for that. And then I’ll present one protocol to you, and show how we built it up, which tries to do authentication between two people in a better, more interesting way.

When I saw the announcement of this year’s workshop theme, I wondered about what I should be speaking about. [Laughter] One possibility was actually suggested by the presentations which were given before mine, particularly Yvo Desmedt’s, which point out the unfriendliness of some of today’s systems. With such “friends” who’s needs “adversaries”? Well, we actually we do need adversary definitions, and my theme is that not only do you have to know your “friend” the system (using the methods that perhaps Ross is going to talk about), but you have to know your “adversary” just as much in order to design and analyse meaningful security protocols. This presentation is related to some joint work which I have done with Adrian Perrig and his two graduate students, Haowen Chan, and Bryan Parno.

One of the challenges in modern systems is the conflict between the desire to run software from a wide variety of untrusted sources and the need to prevent malicious activity by those scripts.

The current standard practice is to attempt to achieve this through permissions, but this has been shown repeatedly to fail in a variety of ways. If permissions are made too granular, they become impossible to configure and so tend to become useless. If they are less granular, loopholes appear through which malicious scripts can wriggle. In either case, providing useful defaults whilst still providing security has proved to be a daunting (or, perhaps, judging on the evidence, impossible) task.

I’m going to talk about putting capabilities into scripting languages. The reason that you might want to put capabilities into a scripting language is because it would be good if we could get a script from any old place and run it without being worried that it was going to do something nasty to us, and more than that, we would like the script to do things that were actually useful, to read and write files, and make network connections, and all the things that we expect programs to be able to do, but exactly what we want it to do.

Now there are these things called capabilities, which nobody likes anymore, that let you do this. So what do I mean by a capability? It’s a word that’s used by lots of people to mean lots of different things. Linux has things it calls capabilities which are actually a kind of fine-grained access control. Java has things that it calls capabilities which are actually another kind of fine grained access control, they are things that if you hold them you can do something, like open this particular file, or send to the printer, or whatever. In order to distinguish these capabilities, people who talk about them these days have started calling them object capabilities, which means that you can think about them as standard object oriented gadgets which are objects in an object oriented language that you cannot look inside, so they’re opaque, and that you can’t get a reference to unless you’re given it, and the general way in which you use them is that you pass them around as parameters, any function can only use the capabilities which it has been passed, or which are within data structures it already owns, functions and models as functions on objects in general, so they usually have a single capability which they can look inside, and they’re the only people who can look inside that capability. And if you write your program right, capabilities correspond to things like read a particular file, write to a particular socket, give me money, that kind of thing. Give me money obviously would be a more general distributed kind of capability, not just within a particular program, so would be represented by bits on the wire as well as a capability in the program.

We describe our work in progress aimed at implementing a multi-hat PDA. Our current prototype is based on SELinux and KDE and accepts a proximity token, in the form of a Bluetooth cellphone, as an alternative authentication method. We analyse in detail the suitability of several alternatives for the graphical environment and underlying OS and we discuss a variety of interesting implementation issues that arose during development.

This is work I did with Frank Stajano, which has come out of some of his stuff that he talked about at last year’s workshop, but I’ll give to anyone who wasn’t here last year a brief synopsis of what he was talking about.

The problem is this: you have a PDA, and this is inherently a single-user machine, that’s how it’s been designed. On your PDA you have some functions which you want to protect, so you might have your diary, and your journal, and your email on it, and you’d quite like to protect this so you put a password on your PDA, but you also have some functions which don’t need a password, so you have a calculator and games on your PDA, and you don’t really need a password for these. But because it’s a single-user machine, obviously only one person’s using it, so you have a password on the whole PDA because it’s all the same person. So if you want to use your calculator you still have to type your password in. The other effect of this is that if you want to lend the calculator to somebody else, demonstrate the nice screen you’ve got on your PDA, you have to type in your password and then you have given them access to all of it. And what we’d quite like to do is to be able to lend someone your PDA to play games on it, or use the calculator, without also giving them the ability to read your email.

Privacy is not an explicit goal of traditional authorisation mechanisms. The contribution of this paper is an authorisation mechanism which takes identity out of the trust management envelope. Our protocol supports weak versions of anonymity and is useful even if anonymity is not required, due to the ability to weaken trust assumptions.

I’m going to talk about some of the work that Partha has done for his PhD dissertation. There’s lots more in there, and if you want to read the hardback edition just get in touch with Partha, but what I’m going to talk about today is the bit concerned with anonymous context-based role activation, and anonymous delegation. The protocols we’ll be looking at use surrogates in various forms, but that’s not essential to the plot. I hope to convince you that doing these things anonymously is not only feasible, but can actually be done maintaining auditability and accountability. This approach allows us to separate identity management from trust management, which has the good consequence of allowing us to localise trust in the system infrastructure. That is a good thing — and therefore these mechanisms are useful — even when anonymity isn’t a requirement at all, and we all know perfectly well who everyone is.