Monthly Archives: March 2006

Award winners

Congratulations to Steven J. Murdoch and George Danezis who were recently awarded the Computer Laboratory Lab Ring (the local alumni association) award for the “most notable publication” (that’s notable as in jolly good) for the past year, written by anyone in the whole lab.

Their paper, “Low cost traffic analysis of Tor”, was presented at the 2005 IEEE Symposium on Security and Privacy (Oakland 2005). It demonstrates a feasible attack, within the designer’s threat model, on the anonymity provided by Tor, the second generation onion routing system.

George was recently back in Cambridge for a couple of days (he’s currently a post-doc visiting fellow at the Katholieke Universiteit Leuven) so we took a photo to commemorate the event (see below). As it happens, Steven will be leaving us for a while as well, to work as an intern at Microsoft Research for a few months… one is reminded of the old joke about the Scotsman coming south of the border and thereby increasing the average intelligence of both countries 🙂

George Danezis and Steven J. Murdoch, most notable publication 2006
George Danezis and Steven J. Murdoch, most notable publication 2006

Fraud or feature?

Dual use technologies are everywhere. Myself and colleagues have been presenting Phish and Chips, and the Man-in-the-Middle Defence at the Security Protocols Workshop this week, in which we describe how the EMV protocol suite can be modified in unintended ways, and that a card interceptor can be used for both fraudulent and beneficial activities.

A second example is how the waters in which internet phishermen angle for account details regularly become muddied by the marketing departments of enterprising banks. Every once in a while, these chaps manage to send out genuine emails entreating the user to click on the link in the email, or to navigate to a site not clearly part of the bank’s site, then provide their personal details.

Today I discovered that the same dilemma has been playing out in the fight to secure the fascia of cash machines against the attachment of illicit skimmers. I was off to work promtly this morning, to open up shop for an ITN TV crew doing a piece on Chip and PIN. After cleverly managing to miss my train, I was forced to take a rather expensive taxi ride to Cambridge — so much so that I had to have the taxi stop for me to withdraw some cash. It was then that I spotted this device attached to the slot of the Barclays Bank ATM on White Horse road in Baldock, Hertfordshire.

ATM attachment detail side

Continue reading Fraud or feature?

Cat with computer virus

Live from IEEE PerCom in Pisa, Italy: “Is your cat infected by a computer virus?“, the paper about writing a virus for RFID tags, by Melanie Rieback, Bruno Crispo (Cambridge security group alumnus) and Andrew Tanenbaum, which got huge press coverage following its “press release” yesterday, has just been given a “best paper for high impact” award. The official Mark Weiser award went to a system paper, but they made up this ad-hoc award for this one… I’m glad it got an award. Somewhat lighthearted and in part debatable, but it was definitely the paper I enjoyed the most.

The authors have a web site for it at (following the perverse fashion of buying a new top level domain for every new thing you do)

Chip and skim

We recently built an EMV transaction interceptor to aid us in understanding the viciously complex EMV protocol suite. A useful byproduct is that we can now give demonstrations of interception and relay attacks on Chip and PIN — topics discussed in our paper Chip and Spin. Since German TV picked up on our interceptor experiments, there has been some discussion about whether these attacks really work, and what it means for Chip and PIN security.

First off, intercepting smartcard communications is not rocket science; EMV is built on the ISO 7816 standard for smartcards. Interceptor hardware necessarily exists for test purposes (Micropross is a well known test rig manufacturer) but it doesn’t come cheap. Not willing to cough up a grand, we decided to do it on the cheap: we wrote a very basic microcontroller program which samples the smartcard I/O data line as fast as it can, and passes the data back via USB for decoding on a laptop.

EMV Interceptor picture

This prototype is a useful price point for the cost of a smartcard interceptor: for example, we bought a suitable microcontroller development board from Siphec for about $60. Our Chip and PIN (EMV) Point-of-Sale Terminal Interceptor page describes both this device and claims that sufficient information can be captured from a trace of an EMV transaction to recover the customer PIN, and to produce a magnetic stripe counterfeit of the card.

That we built a working interceptor is not under dispute, but is the above claim true? Would it actually work in practice? For this goal, a number of extrapolations must hold true:

  • The PIN must travel in the clear across the wires to the smartcard. UK cards are SDA cards, so the PIN is not encrypted. In theory the PIN could be routed for verification at the bank rather than by the card, but the UK also opted for local verification only.
  • The customer PAN and CVV1 must be sent by the smartcard. More generally, all the information required to reconstruct the magnetic stripe must be present. The PAN is clearly sent as it is required for the EMV transaction itself. In the half dozen or so UK cards we have examined, the same CVV1 appeared to present in the chip data as on the magstripe, though we were aware of some suggestions that the CVV1 was blanked out on the chip equivalent data. The EMV specification says that all records stored on the chip are read out during a transaction, and the traces appear to confirm this.
  • There must be no further secret authentication mechanisms for the card or magstripe. In Germany, magstripe cards carry a hidden “MM-code” which is correlated with a copy encoded on the magstripe; the method to read the MM-code is kept secret. In the USA there is some use of automated counterfeit hologram detection. It seems no such methods are in use in the UK; journalist Jonathan Maitland from Tonight with Trevor MacDonald successfully produced and used a counterfeit white card produced purely from a dump of track 1 and 2 magstripe data.
  • A suitable target ATM must be found at which to use the counterfeit card. Clearly there are plenty of ATMs in foreign countries which do not support Chip and PIN, so targets do exist. Within the UK there are three ways for an ATM to be vulnerable. First, if it has not been upgraded to support chip cards, it must necessarily use the magstripe. Second, if the chip-enabled ATM cannot tell with certainty that a card is supposed to be a chip card, then it may assume it is a magstripe card. Seeing as practically all UK ATMs are online the issuing bank can always be queried, so this second vulnerability mode is unlikely. Third, if the ATM supports fallback to magstripe, for instance in the case of damaged chips, then it will work. Conditions under which ATMs permit fallback actually appear to be quite complex, dependent for example on time of day and fraud history on that machine. There was certainly no problem finding viable ATMs in the UK when the Trevor MacDonald program aired, this time last year.
  • It must be possible to adequately miniaturise and camouflage the interceptor. Miniaturisation of the circuitry is not the bottleneck here, very small form-factor microcontrollers can be found, and few other discrete components are needed. The real miniaturisation challenge comes in gaining physical access to the electrical contacts covertly. The reader slot is wide enough to admit a thin second item, such as a flexible PCB, or maybe some other sort of plastic sheet with conductive ink, but the space is of the order of 0.1 mm, a typical card being about 0.8 mm thick. The alternative is not to go for a miniature solution per se, but a well camouflaged fake slot which sits outside the main slot. Different form-factor terminals would clearly have different optimal designs for cheap interceptors.
  • The POS terminal must not be able to detect the presence of an interceptor. Some modernised ATMs are able to detect unauthorised attachments designed to directly skim PIN and magstripe, there is no fundamental reason why such technology could not be applied to POS terminals as well. However we have found that there definitely are UK POS terminals which do not detect such attachments, for reasons of cost, we suspect.

Is there missing piece to this jigsaw that we have overlooked in our investigations, or are banks simply reluctant to admit that POS terminals are at least equally vulnerable to the same sorts of magstripe skimming attacks as ATMs? I’m eager to find out.

Banks don’t help fight phishing

I recently got an email from Bank of America offering me a pretty good credit card deal. Usually, I chuck those offers away as spam (both electronic and physical) but this time I decided to bite.

The “apply now” button pointed to…, fair enough. I click. But wait… IE6 says…

Certificate warning IE

Firefox provides more info without layers of abstraction…

Certificate warning FF

I clicked “OK” and got to…! (you’ll notice that going there directly redirects to, so only when you click “apply” do you get to see

I consequently emailed BofA with my concerns and got this (surprisingly expedient) reply:

“We recognize that any unsolicited e-mail, legitimate or otherwise, is reason for concern. I can assure you that is a legitimate website of Bank of America.”

Well, not much assurance there since I replied to the original email (, but a whois query confirms that indeed belongs to BofA. What percentage of the population would go beyond clicking that “OK” on the IE warning as just another annoyance? You know the answer.

So, BofA got three things wrong. Firstly, they had links in the body of the email; the argument has been beaten to the ground… don’t educate people to click them. If the bank has great offers, they should have them available when people log into their accounts. Secondly, they messed up on the certificate… it’s for, not what appears in the address bar, And finally, they used an unfamiliar domain to process the application. Why? I think the answer lies somewhere in the marketing department where they decided that is cooler sounding than sound security measures and long term good customer training.

Update: Richard mentioned that the rapid response meant that BofA have heard this concern once before. I found this thread [] discussing in August 2003! Which adds a fourth thing BofA did wrong: they didn’t fix it!

Video eavesdropping demo at CeBIT 2006

If you happen to be at CeBIT 2006 in Hanover this week, don’t miss a little demonstration of compromising video emanations that I developed (Halle 6, Stand A42, booth of GBS). It shows how easily now cheap FPGA DSP evaluation boards can be turned into impressive home-brew eavesdropping devices.

COVISP demonstration setup at CeBIT 2006

The system shown consists of a log-periodic antenna (not on the photo), a Dynamic Sciences R1250 wideband receiver, and an Altera FPGA DSP Development Kit, Stratix II Edition. The FPGA board is the implementation platform for my COVISP-1 (compromising video emanations processor) circuit. It receives the 30 MHz intermediate-frequency output signal from the UHF tuner, samples it with 12-bit resolution at 120 MHz, applies a number of signal-processing steps (AM demodulation, gain control, clipping, blanking), and outputs the result – along with sync-pulses – onto the connected VGA monitor. It implements all the controls necessary to adjust it precisely and comfortably to the video mode of the eavesdropping target, including a video clock synthesizer with a frequency-resolution of about 1 part-per-billion, necessary for accurate synchronization of the image.
The eavesdropping target to which the demo setup is tuned in on the above picture is a PC with a flat-panel display:
Eavesdropping target of COVISP demonstration at CeBIT 2006

It belongs to a nearby Russian stand, is about 25 meters away from our antenna. Its PowerPoint presentation is clearly readable on our eavesdropping system, which managed to isolate this signal from the many hundred PCs located in the same room.

BBC article on new Chinese TLDs

Since my blog post last week, discussion continues on what has actually happened with the new Chinese TLDs and what the consequences will be. Rebecca MacKinnon’s posting on CircleID triggered an interesting discussion. It has also been mentioned on a few blogs including My Heart’s in Accra, Joho the Blog, China Digital Times, Shanghaiist, Virtual China, the LINX public affairs news and even in a Czech blog which I can’t understand. The ICANN Generic Names Supporting Organization (GNSO) mailing list has a thread discussing the move, as does the DomainState forum.

Michael Geist wrote an article for the BBC, which was also featured in Toronto Star. It includes the quote:

The Chinese development is also noteworthy because it works. Researchers at Cambridge University report that Chinese ISPs recognize the new domains.

I presume this is based on my blog posting, since I am not aware of anyone else in Cambridge having looked into this.

Also in the news is a statement from CNNIC, and reported in People’s Daily Online. CNNIC say that reports of new TLDs are inaccurate, but does not explain what the actual situation is. CNNIC’s DNS servers resolve the new TLDs and claim to be authoritative, but perhaps CNNIC means that they are still only experimental, or simply that the press release did not announce any change. CNNIC are accepting registrations under the new TLDs, which does suggest they consider them official.

As for the discussion about whether what China has done is technically “splitting the root”, in the GNSO thread, Karl Auerbach gives a very succinct description:

It’s a somewhat pointless game of semantics about whether this circumstance is a “split” root or not. However, it has most of the characteristics that ICP3 [link mine] wails about – most particularly names not being globally visible.

I’d say that this situation quacks like a duck and walks like a duck: it’s a non-ICANN approved addition to the top level names of the DNS which is visible to some internet users and not to others.

(And this appearance of a new TLD is true without benefit of plugins or internet exploders.)

It may be an experiment, but if so it’s a rather large one.

New Chinese TLDs

On 28 February, People’s Daily Online published an article entitled “China adds top-level domain names”. This suggested that China was going to take over .com and .net and split off from the conventional domains managed by ICANN and operated by Verisign. This appears to be not the case, rather the result of a mis-translation. As pointed out by Rebecca MacKinnon, the new top level domains (TLDs) are .中国 (meaning “China”) .公司 (meaning “company”), and .网络 (meaning “net”), which do not conflict with any ICANN managed TLDs.

The normal way to create new TLDs without ICANN’s permission is known as “splitting the root” since it involves creating a new root name server and replacing the root zone file distributed by IANA with your own. For some background on the role of the root zone file there is a short introduction and a slightly longer version by Daniel Karrenberg. Alternative roots are not new, but what makes the current situation different is that the new TLDs have a (powerful) government’s backing, and with around 100m Internet users (second only to the US) has the potential to have a far larger user base than any that have come before it.

There is still some uncertainty on how the new TLDs have been implemented. i-DNS produces a plugin for Microsoft Internet Explorer which allows it to access internationalised domain names as until version 7, IE cannot do this natively. In March 2005 they announced a partnership with the Chinese Ministry of Information Industry to develop the new TLDs and add support to their plugin. Some commenters have assumed that this is the only mechanism used to implement the new TLDs, but as mentioned in the press release, it seems that ISPs have also modified their servers, allowing access to these TLDs from within China without the user having to install any additional software. I do not know when this change was made and how complete the implementation is, but James Seng describes the TLDs as being in operation for 3 years.

It appears that technically China has not “split the root” since there seems to be no new root server. Instead, each ISP might have manually added the three new TLDs to their DNS server configuration. When a domain name under the ICANN TLDs (.com, .net, .uk, etc…) is resolved, the server would go to an ICANN root server to find out which organisation is responsible for allocating second level domains. However, when a domain name under one of the new TLDs is requested, the DNS server already knows the nameserver it needs to ask next and can skip the root server lookup. The advantage of this approach for China is that it avoids the cost and difficulty of setting up a new root server, but the disadvantage is that to add another TLD in the future they would have to ask all the ISPs again, rather than adding it to their root.

Despite this technicality, what China appears to have done is externally almost indistinguishable from splitting the root and carries the same consequences. The primary problem is that a link using one of the new TLDs will work in China but not outside (without a user installing the plugin, or their ISP making a configuration change). This breaks the universality of the Internet and while I will not go into further detail here, the Internet Architecture Board discusses the effects of a split root in RFC 2826, which is in addition to problems of the landrush resulting from any new domain.

I am not familiar with the ISP landscape in China, but I have tried to do some tests to better understand how these changes have been implemented. For testing I am using a DNS server ( which I understand to be one used by the customers of a Chinese ISP, but which also allows access from outside. As an example, I used “北京大学.中国” which I think means Peking University in the new “.China” TLD. As Unicode cannot be used directly with DNS, it needs to be translated into Punycode. This gives xn--1lq90ic7fzpc.xn--fiqs8s.

When I ask the Chinese DNS server to resolve this domain name, I get this answer:

$ dig xn--1lq90ic7fzpc.xn--fiqs8s A
xn--1lq90ic7fzpc.xn--fiqs8s. 3600 IN CNAME 47863 IN CNAME 85892 IN A

This means that according to, the domain 北京大学.中国 is another name for and its IP address

If this nameserver was configured only with the IANA distributed root zone file, this request would have failed (as it does on my UK DNS server). Instead, it looks like this ISP has somehow added these three new TLDs. To find out more I asked the server for its root zone, i.e. where it will send requests for TLDs it has not encountered before:

$ dig . NS

It returned only the 13 IANA root servers ([A-M] These do not list the new Chinese TLDs but the server still knows about them.

Here I ask the server which nameserver it thinks is authoritative for .中国 (.China and in Punycode — xn--fiqs8s):

$ dig xn--fiqs8s SOA
xn--fiqs8s. 3600 IN SOA 2006030104 3600 900 604800 3600

This means that when this server wants to resolve a domain under .中国 is will ask I get the same result with .公司 (“company”), and .网络 (“net”). will also resolve domains under these TLDs and considers itself to be authoritive.

Several questions still remain. It is possible that the name server I used is not representative of Chinese ISPs. Also, despite it not listing any alternate roots, it is still conceivable that the server is using one. It may also be acting differently because I am outside of its customer network. However, I think it does demonstrate that there is something happening in addition to the i-DNS plugin.

I did briefly try this plugin and examine some aspects of how it works. Internet Explorer 6 and below do not support internationalised domain names (IDNA) at all. Even though Firefox does, as my DNS server in the UK only uses the IANA root servers, only the ICANN defined TLDs will work. So http://北京大学.cn/ (Peking University) will work in Firefox in the UK and China, as the TLD is .cn, but http://北京大学.中国/ will only work in China, as the TLD is one of the new non-ICANN domains.

Installing the i-DNS plugin adds IDNA support to Internet Explorer but also adds support for the new TLDs. I am not aware of all the details, but when I visit it redirects the user to, redirects to and to The nameserver for is controlled by i-DNS and, as with the DNS server in China, uses for further lookups.

It seems that these new TLDs are more complicated than it might first have looked, and this post by no means explains everything. I hope that others will be able to find out more. It remains to be seen what the consequences of this move will be. In their advertisement, i-DNS states that 50m users already have access to these TLDs and if the 4 ISPs which provide access to 95% of China’s Internet users add the TLDs then the remaining 5% will inevitably follow.

Also non-Chinese ISPs with a significant number of Chinese-speaking users will be under pressure to add these TLDs, and have very little incentive to not do so. While previous alternate roots have languished in the obscurity of a narrow user-base, the potential of 100m (and growing) users will make this TLD hard to ignore. Perhaps in an attempt to avoid a split Internet, ICANN will adopt the TLDs and so roll them out to the standard root servers. Whatever they choose, I hope the disruption to the Internet from the resulting politics will not be too severe.