Catálogo de publicaciones - libros

I want to talk about the real world, where authentication protocols are extremely insecure, and I’m going to try and explain to you why phishing is so profitable.

Why does phishing work? Basically because con artists are really good at persuading people to do really dumb things – and we just have to face up to this. What’s changed recently is that in order to run a con you no longer need a printing press in the cellar to produce all the props. Anybody can produce web pages which look just as good as the professional stuff. But the really deep problem is that the underlying protocols are rubbish and that’s what my paper is about.

Trust Management [1,4,10] is an approach to constructing and interpreting the trust relationships among public-keys that are used to mediate security-critical actions. Cryptographic credentials are used to specify delegation of authorisation among public keys. Existing trust management schemes are operational in nature, defining security in terms of specific controls such as delegation chains, threshold schemes, and so forth.

However, Trust Management approaches tend not to consider whether a particular authorisation policy is well designed in the sense that a principle cannot somehow bypass the intent of a complex series of authorisation delegations via some unexpected circuitous route. In an open system no individual has a complete picture of all the resources and services that are available. Unlike the administrator who ‘sees everything’ in a traditional closed system, the principals of an open system are often ordinary users and are open to confusion and subterfuge when interacting with resources and services. These users may inadvertently delegate un-intended authorisation to recipients.

In this paper we introduce the problem of , whereby, in a poorly designed system, delegation chains that are used by principals to prove authorisation may not actually reflect the original intention of all of the participants in the chain.

This talk is about work by myself and Hongbin Zhou, who’s a PhD student in Cork (except he’s here today). One of the problems that we’re interested in is just simple authorisation, whether or not somebody is allowed to perform some action, get access to some resource. In the good old days we had the traditional view of system administrators who had control over everything, and they had, or at least liked to think that they had, a very clear picture of what the resources were for, and who should have access to the resources, and so on. As a consequence they tend to exercise very tight control, they don’t like giving away authorisation to resources, and it’s usually a battle for somebody to get additional access to any resource. Administrators in these closed systems exercise their principle of “no privilege”, nobody’s allowed to do anything. As a consequence, the opportunity to subvert an administrator is very small, so you really have to work hard to get anywhere within one of these closed systems.

We examine several ad-hoc pairing protocols that strengthen their radio exchanges with additional transmissions over another channel, for example a screen showing graphically encoded information to a camera. Additional channels may have limited capacity and may still be subject to eavesdropping, but they may offer specific advantages over radio such as data origin authenticity. A single protocol may profitably use more than one channel, each with its own specific security properties, for different messages in its trace. Making this option explicit allows for further advances in protocol design.

We also present an intriguing asymmetric protocol that achieves results comparable to mutual authentication even though the verification happens only in one direction.

So these protocols only work if you actually try and connect devices to each other?

Because of this type of auxiliary channel, yes, they would need to be next to each other.

If you want to be sure that the two things that you’re holding are connected to each other and not to some third party, yes?

Yes. In the past, someone who can eavesdrop on this auxiliary channel will be able to break your system, so what we’re saying here is that with our protocol, they can eavesdrop all they like, but by the time they eavesdrop it’s too late. They have to break the hard problem, to calculate the right keys.

I present my research on combining cryptography and iris biometrics. This is work with Ross Anderson and John Daugman. It is a short talk so I will leave out the technical detail.

The motivation of the research is to incorporate advanced biometric authentication features into cryptography. We find that cryptography lacks the involvement of a human factor. In authentication, you would use a password or a token, but there is no real human factor involved. We studied the iris biometric because it is one of the most reliable biometrics discovered so far. There are however certain issues with the iris biometric. First, it is fuzzy. Second, its storage is quite controversial for privacy reasons. And third, it cannot be kept secret by its very nature. These limitations apply to biometrics in general.

We examine security protocols for the Grid Security Infrastructure (GSI) version 2 and identify a weakness of poor scalability as a result of GSI’s authentication framework requiring heavy interactions between a user-side client machine and resource suppliers. We improve the GSI architecture and protocols by proposing an alternative authentication framework for GSI, which uses dynamic public/private key pairs to avoid frequent communications to a significant extent. The improvement to the GSI security protocols is enabled by a novel application of an emerging cryptographic technique from bilinear pairings.

My talk which includes some background information about grid computing, grid security, security infrastructure, and also some of the limitations, our proposal on some security protocols, what are the improvements, and a summary.

A computational grid allows a user to submit a very computational intensive job from different kind of platforms to some remote resources, so that these remote resources can execute the job on behalf of the user, and return the relevant result back to the user. The nature of the job is normally very complex and complicated such as those for advanced science and engineering applications which normally require a long time to complete.

Many users routinely log in to their system with system administrator privileges. This is especially true of home users. The advantage of this setup is that these users can do everything necessary to fulfil their tasks with the computer. The disadvantage is that every program running in the users context can make arbitrary modifications to the system. Malicious programs and scripts often take advantage of this and silently change important parameters. We propose to verify that these changes were initiated by a human by a ceremony making use of a CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart). We compare this approach with other methods of achieving the same goal, i.e. passwords, secure path and access control based on zone of origin of the code.

This talk is about putting the human in the loop, or rather making sure that there is a human in the loop. Sometimes we have this feeling that, while we’re still responsible for what the computer does, we don’t have control over what it does, and it would be nice to make sure that at least some human has seen what goes on. So this is about countering automated exploits with system security CAPTCHAs, I know it is a bad idea to have an acronym in the title but I was at Microsoft Research when we did this work. CAPTCHA for those of you who don’t know, it is a Completely Automated Public Turing Test to Tell Computers and Humans Apart.