Catálogo de publicaciones - libros

Every year we have a theme and it’s always difficult to ignore the theme if you don’t know what it is, so there’s a tradition that somebody spends five minutes at the beginning telling you what the theme is so that you can ignore it.

The theme this year is “the system likes you and wants to be your friend”. The thinking behind this is that there might be advantages to looking at security in the context of more general design problems, and that those investigating the general properties of system design and those of us in the security community might have more to say to each other than we currently seem to.

This paper recounts some lessons that we learned from the deployment of host-to-host IPsec in a large corporate network. Several security issues arise from mismatches between the different identifier spaces used by applications, by the IPsec security policy database, and by the security infrastructure (X.509 certificates or Kerberos). Mobile hosts encounter additional problems because private IP addresses are not globally unique, and because they rely on an untrusted DNS server at the visited network. We also discuss a feature interaction in an enhanced IPsec firewall mechanism. The potential solutions are to relax the transparency of IPsec protection, to put applications directly in charge of their security and, in the long term, to redesign the security protocols not to use IP addresses as host identifiers.

I am going to talk about some problems with IPSec, especially about how IPSec policies are specified, and whether that matches the kind of security requirements we had in the beginning, and which were why we introduced IPSec. Maybe everyone is familiar with IPSec, but it might be useful to have the same kind of picture in mind, because you can look at these things from various points of view.

Most of the research in the past has been on things like, is this security protocol secure, is this authenticated key exchange protocol secure. In this talk I am just going to assume that you have some authenticated key exchange protocol and that it is secure. Also there’s been lots of work on the cryptographic algorithms: is this encryption (or Mac) the most efficient and the most secure one known, or the best compromise between the two. And that’s another thing that I’m not going to talk about, I shall just assume it happens. I’m more interested in the architectural type of thing, like the security policy and how it is specified.

We implement and demonstrate a passive attack on the Bluetooth authentication protocol used to connect two devices to each other. Using a protocol analyzer and a brute-force attack on the PIN, we recover the link key shared by two devices. With this secret we can then decrypt any encrypted traffic between the devices as well as, potentially, impersonate the devices to each other. We then implement an alternative pairing protocol that is more robust against passive attacks and against active man-in-the-middle attacks. The price of the added security offered by the new protocol is its use of asymmetric cryptography, traditionally considered infeasible on handheld devices. We show that an implementation based on elliptic curves is well within the possibility of a modern handphone and has negligible effects on speed and user experience.

The Bluetooth pairing protocol is the one that takes place when two Bluetooth devices get together and want to authenticate to each other. I shall start by giving a high level summary of our work.

Firstly, “Look Ma, we can crack Bluetooth!”, we demonstrate a crack by a passive adversary. On its own this doesn’t look very interesting academically because, from the protocol itself, it is clear that this could be done. So next we ask if this problem can be fixed. The answer is affirmative, and we show how, but this looks like cheating because we fixed it in a way that the original designers of the protocol thought was not allowed. However we then argue that this was a sensible thing to do, and that maybe it is appropriate to relax the constraints that they set on themselves in the first place.

This paper introduces an off-tag RFID access control mechanism called “Selective RFID Jamming”. Selective RFID Jamming protects low-cost RFID tags by enforcing access control on their behalf, in a similar manner to the RFID Blocker Tag. However, Selective RFID Jamming is novel because it uses an active mobile device to enforce centralized ACL-based access control policies. Selective RFID Jamming also solves a Differential Signal Analysis attack to which the RFID Blocker Tag is susceptible.

I am here today to talk about some of the security implications of Radio Frequency Identification. RFID tags are remotely-powered data carriers that resemble the theft control tags that you might find in a sweater when buying clothing from a store. Like theft-control tags, RFID tags are powered and accessed from a distance using radio waves, but RFID tags differ from theft-control tags in that they tend to have more storage space and processing power. RFID tags have security issues that have been exposed in the past few years. The heart of the problem is that RFID tags don’t usually support cryptography, plus RFID application scenarios are usually not conducive to commonly performed security operations like key management; in fact, many security and privacy issues that generally exist in ubiquitous computing reappear in RFID applications specifically.

Our paper first reviews some of the most critical issues related to the introduction of Chip & PIN card payment authorisation, and then outlines one part of our experiment that we decided to undertake to validate some of our views and ideas. Our experiment examines, in two phases, whether introduction of this authorisation method is advantageous for an opportunistic thief and whether the customer truly benefits from the Chip & PIN technology with respect to this opportunistic thief.

This work has been done with over 40 participants in a simple experiment we decided to undertake in Brno this year. With the introduction of Chip-and-PIN payment authorisation we very often hear that that shoulder-surfing is easier than forging the signature, and different groups of people argue against or for this statement. We were not sure whether the authorisation of the transaction from the point of view of the customer, the signature or entering the PIN, really makes a difference for an opportunistic thief who can observe your transaction in the shop, then steal your card and try to forge the operation on your behalf afterwards. And so we decided to undertake an experiment that would answer this question to us. And here we didn’t care about any other threats, we considered the opportunistic thief, and a simple transaction in the shop with the point of sale terminal.

The users of online banking systems are currently at risk from “phishing” scams. Confidence tricksters persuade them to visit fraudulent websites and use their authentication credentials to steal from the victims’ accounts. We analyse the authentication protocols used for online banking, find that they are entirely inadequate, and consider how to improve systems design so as to discourage attacks.