Catálogo de publicaciones - libros

Well hello, and welcome to the twelfth Security Protocols Workshop. When this all started we had no idea what a juggernaut we were creating, and it’s particularly nice to see so many young people here. [Laughter]

This paper identifies certain privacy threats that apply to anonymous credential systems. The focus is on timing attacks that apply even if the system is cryptographically secure. The paper provides some simple heuristics that aim to mitigate the exposure to the threats and identifies directions for further research.

Rather sadly, I’m afraid, I don’t think my talk will be terribly controversial.

I want to talk about anonymity, a special aspect of privacy, and anonymous credentials. Whilst one might have a scheme which is theoretically secure in some sense, of course there are limits to what that might guarantee you about anonymity, just through the practicalities of using this scheme. Having observed that, what might one do in order to try and maximise the level of anonymity that one achieves in the practical use of a credential scheme? I’m not going to look at scheme-specific issues, I’m not going to look at proofs of security, or details of how particular credential schemes work, but just assume some general properties of credential schemes, and look at what practical implications there are from the use of such schemes. This is based on joint work with a student of mine, Andreas Pashalidis, and as always, this is 90% Andreas and 10that accounts for the 10% of errors that will naturally creep into the talk.

It is usually the case that before a transaction can take place, some mutual trust must be established between the participants. On-line, doing so requires the exchange of some certified information about the participants. The easy solution is to disclose one’s identity and reveal all of one’s certificates to establish such a trust relationship. However, it is clear that such an approach is unsatisfactory from a privacy point of view. In fact, often revealing information that uniquely corresponds to a given individual is a bad idea from the privacy point of view.

In this survey paper we describe a framework where for each transaction there is a precise specification of what pieces of certified data is revealed to each participant. We show how to specify transactions in this framework, give examples of transactions that use it, and describe the cryptographic building blocks that this framework is built upon. We conclude with bibliographic notes on the state-of-the-art in this area.

Welcome to this talk on linked credential systems and controlled release of certified data. This talk is actually about what cryptographics can do for mass protection; more precisely it’s about real world cryptographic techniques to control the release of certified data.

How can we design a PDA that is at the same time secure and usable? In current implementations the two properties are mutually exclusive. Because normal users find password entry inconvenient, the balance usually shifts away from security, leaving the PDA vulnerable if lost or stolen.

We begin by envisaging what an ideal PDA authentication mechanism might look like and by carefully examining alternatives to passwords such as tokens and biometrics.

We then expose another aspect of the security vs. usability problem. In many cases, when we turn on our PDA, we only access functionality (dictionary, calculator, web browser...) that requires no access to private data stored in the machine; why, then, should we pay the usability penalty of authentication in such cases? Moreover, we may want to grant another person temporary access to such “harmless” functionality, but without being forced to grant them unrestricted access to the whole machine.

To solve this problem we describe a system in which we may assign more than one “hat” to the owner of this single-user device, with each hat having specific privileges. The machine supports concurrent graphical logins for several hats and a convenient mechanism to switch between them. There is also provision for a userid associated with “no hat”, to which one can switch without the need for authentication, and which can access all the harmless functionality. This scheme turns out to be applicable and useful well beyond the limited realm of PDAs.

One of the problems with biometrics is that the incentives are all wrong. In the case of most biometric identity systems the benefit is for the operator of the system, who usually wants to prevent transfer of usability of credentials, not for the user of the system herself. When I give my biometric identity to the passport agency this is for the benefit of the passport system, not for my system. In fact it degrades my privacy, because now the passport authorities have enough information to fake my biometrics in other applications. This might be an instance in which the semantics of the trust properties of the application are the problem.

Security protocols typically employ an authentication phase followed by a protected data exchange. In some cases, such TLS, these two phases are tightly integrated, while in other cases, such as EAP (Extensible Authentication Protocol) and Kerberos, they are separate and often implemented in different endpoints. However, careless application of this separation has lead to several vulnerabilities. In this paper we discuss reasons why this separation is often useful, what mistakes have been made, and what these mistakes have in common. We then describe some approaches how these problems could be avoided, especially focusing on EAP in wireless LANs. We also present some engineering observations that should be taken into account when designing reusable authentication components in the future.

My talk is on authentication components. What I mean by an authentication component is basically a reusable building block. I’m talking about building blocks in a strictly engineering sense (there is very little novel cryptograph use involved), building blocks that are useful to system designers when they’re designing a system and need a protocol for doing something, and they don’t want to reinvent all the cryptographic stuff themselves. Usually they are not experts in that either, so it’s a good thing that they don’t always reinvent things from scratch.

As the Internet has gained widespread use, and advanced technologies such as high-speed multi-media technologies and automated digital monitoring have become a reality, privacy is at the greatest risk of all time. At the same time, sophisticated threats from hackers, terrorists, thieves, and others that would abuse privacy highlight the need to find technologies that provide some accountability. However, the goals of accountability and of privacy appear to be in contradiction: accountability tends to be about determining which entities committed which actions, while privacy seeks to hide this information.

In this paper, we discuss the apparent conflict that exists between privacy and accountability. We survey some of the issues in privacy and in accountability and highlight research directions for balancing the needs of both.