Category Archives: Privacy technology

Anonymous communication, data protection

Hot or Not: Revealing Hidden Services by their Clock Skew

Hardware & signals, Privacy technology

Next month I will be presenting my paper “Hot or Not: Revealing Hidden Services by their Clock Skew” at the 13th ACM Conference on Computer and Communications Security (CCS) held in Alexandria, Virginia.

It is well known that quartz crystals, as used for controlling system clocks of computers, change speed when their temperature is altered. The paper shows how to use this effect to attack anonymity systems. One such attack is to observe timestamps from a PC connected to the Internet and watch how the frequency of the system clock changes.

Absolute clock skew has been previously used to tell whether two apparently different machines are in fact running on the same hardware. My paper adds that because the skew depends on temperature, in principle, a PC can be located by finding out when the day starts and how long it is, or just observing that the pattern is the same as a computer in a known location.

However, the paper is centered around hidden services. This is a feature of Tor which allows servers to be run without giving away the identity of the operator. These can be attacked by repeatedly connecting to the hidden service, causing its CPU load, hence temperature, to increase and so change the clockskew. Then the attacker requests timestamps from all candidate servers and finds the one demonstrating the expected clockskew pattern. I tested this with a private Tor network and it works surprisingly well.

In the graph below, the temperature (orange circles) is modulated by either exercising the hidden service or not. This in turn alters the measured clock skew (blue triangles). The induced load pattern is clear in the clock skew and an attacker could use this to de-anonymise a hidden service. More details can be found in the paper (PDF 1.5M).

Clock skew graph

I happened upon this effect in a lucky accident, while trying to improve upon the results of the paper “Remote physical device fingerprinting“. A previous paper of mine, “Embedding Covert Channels into TCP/IP” showed how to extract high-precision timestamps from the Linux TCP initial sequence number generator. When I tested this hypothesis it did indeed improve the accuracy of clock skew measurement, to the extent that I noticed an unusual peak at about the time cron caused the hard disk on my test machine to spin-up. Eventually I realised the potential for this effect and ran the necessary further experiments to write the paper.

After ID Cards…

Legal issues, Privacy technology

The next government initiative to undermine privacy is the Children’s Database project. I am one of the authors of a report on this, which was written for the Information Commissioner and will be published later in September. Press interest is starting to mount (see the Telegraph, the Tiimes, the Evening Standard and the Daily Mail), and there will be a TV programme on the subject today (More 4 at half past seven). If you’re in the UK and are interested in privacy or computer security, that might be worth watching.

The project aims at linking up all the government systems that keep information on kids. Your kids’ schoolteachers will be able to see not just their school records but also their medical records, social work records, police records and probation records; see here for the background. I can’t reveal the contents of the report prior to publication but I am reminded of Brian Gladman’s punchline in his talk at SFS8: ‘You can have scale, or functionality, or security.If you’re smart you can build a system with any two of these. But you can’t have all three.’

As well as the technical objections there are legal objections – and strong practical objections from social workers who believe that the project is putting children in harm’s way.

Protocol design is hard — Flaws in ScatterChat

Cryptology, Internet censorship, Privacy technology

At the recent HOPE conference, the “secure instant messaging (IM) client”, ScatterChat, was released in a blaze of publicity. It was designed by J. Salvatore Testa II to allow human rights and democracy activists to securely communicate while under surveillance. It uses cryptography to protect confidentiality and authenticity, and integrates Tor to provide anonymity and is bundled with an easy to use user interface. Sadly not everything is as good as it sounds.

When I first started supervising undergraduates at Cambridge, Richard Clayton explained that the real purpose of the security course was to teach students not to invent the following (in increasing order of importance): protocols, hash functions, block ciphers and modes of operation. Academic literature is scattered with the bones of flawed proposals for all of these, despite being designed by very capable and experienced cryptographers. Instead, wherever possible, implementors should use peer-reviewed building blocks, as normally there is already a solution which can do the job, but has withstood more analysis and so is more likely to be secure.

Unfortunately, ScatterChat uses both a custom protocol and mode of operation, neither which are as secure as hoped. While looking at the developer documentation I found a few problems and reported them to the author. As always, there is the question of whether such vulnerabilities should be disclosed. It is likely that these problems would be discovered eventually, so it is better for them to be caught early and users allowed to take precautions, rather than attackers who independently find the weaknesses being able to exploit them with impunity. Also, I hope this will serve as a cautionary tale, reminding software designers that cryptography and protocol design is fraught with difficulties so is better managed through open peer-review.

The most serious of the three vulnerabilities was published today in an advisory (technical version), assigned CVE-2006-4021, from the ScatterChat author, but I also found two lesser ones. The three vulnerabilities are as follows (in increasing order of severity): Continue reading Protocol design is hard — Flaws in ScatterChat →

Anonymous data that isn't

Legal issues, Privacy technology

AOL has recently been embarrassed after it released data on the searches performed by 658,000 subscribers. Their names had been replaced by numbers, but this was not enough to stop personal information leaking. The AOL folks just didn’t understand that protecting data using de-identification is hard.

They are not alone. An NHS document obtained under the Freedom of Information Act describes how officials are building a “Secondary Uses Service” which will contain large amounts of personal health information harvested from hospital and other records. It’s proposed that ever-larger numbers of people will have access to this information as it is progressively de-identified. It seems that officials are just beginning to realise how difficult it will be to protect patient privacy — especially as your deidentified medical record will generally have your postcode. There are only a few houses at each postcode; knowing that, plus a patient’s age, usually tells you whose record it is. The NHS proposes to set up an “Information Governance Board” to think about the problem. Meanwhile, system development steams ahead.

Clearly, the uses and limitations of anonymisation ought to be more widely understood. There’s more on the subject at the American Statistical Association website, on my web page and in chapter 8 of my book.

Protecting software distribution with a cryptographic build process

Cryptology, Privacy technology

At the rump session of PET 2006 I presented a simple idea on how to defend against a targeted attacks on software distribution. There were some misunderstandings after my 5 minute description, so I thought it would help to put the idea down in writing and I also hope to attract more discussion and a larger audience.

Consider a security-critical open source application; here I will use the example of Tor. The source-code is signed with the developer’s private key and users have the ability to verify the signature and build the application with a trustworthy compiler. I will also assume that if a backdoor is introduced in a deployed version, someone will notice, following from Linus’s law — “given enough eyeballs, all bugs are shallow”. These assumptions are debatable, for example the threats of compiler backdoors have been known for some time and subtle security vulnerabilities are hard to find. However a backdoor in the Linux kernel was discovered, and the anonymous reporter of a flaw in Tor’s Diffie-Hellman implementation probably found it through examining the source, so I think my assumptions are at least partially valid.

The developer’s signature protects against an attacker mounting a man-in-the-middle attack and modifying a particular user’s download. If the developer’s key (or the developer) is compromised then a backdoor could be inserted, but from the above assumptions, if this version is widely distributed, someone will discover the flaw and raise the alarm. However, there is no mechanism that protects against an attacker with access to the developer’s key singling out a user and adding a backdoor to only the version they download. Even if that user is diligent, the signature will check out fine. As the backdoor is only present in one version, the “many eyeballs” do not help. To defend against this attack, a user needs to find out if the version they download is the same as what other people receive and have the opportunity to verify.

My proposal is that the application build process should first calculate the hash of the source code, embed it in the binary and make it remotely accessible. Tor already has a mechanism for the last step, because each server publishes a directory descriptor which could include this hash. Multiple directory servers collect these and allow them to be downloaded by a web browser. Then when a user downloads the Tor source code, he can use the operating system provided hashing utility to check that the package he has matches a commonly deployed one.

If a particular version claims to have been deployed for some time, but no server displays a matching hash, then the user knows that there is a problem. The verification must be performed manually for now, but an operating system provider could produce a trusted tool for automating this. Note that server operators need to perform no extra work (the build process is automated) and only users who believe they may be targeted need perform the extra verification steps.

This might seem similar to the remote-attestation feature of Trusted Computing. Here, computers are fitted with special hardware, a Trusted Platform Module (TPM), which can produce a hard to forge proof of the software currently running. Because it is implemented in tamper-resistant hardware, even the owner of the computer cannot produce a fake statement, without breaking the TPM’s defences. This feature is needed for applications including DRM, but comes with added risks.

The use of TPMs to protect anonymity networks has been suggested, but the important difference between my proposal and TPM remote-attestation is that I assume most servers are honest, so will not lie about the software they are running. They have no incentive to do so, unless they want to harm the anonymity of the users, and if enough servers are malicious then there is no need to modify the client users are running, as the network is broken already. So there is no need for special hardware to implement my proposal, although if it is present, it could be used.

I hope this makes my scheme clearer and I am happy to receive comments and suggestions. I am particularly interested in whether there are any flaws in the design, whether the threat model is reasonable and if the effort in deployment and use is worth the increased resistance to attack.

Watching them watching me

Banking security, Privacy technology

On and off for the past two years, I have been investigating anti-counterfeiting measures in banknotes, in particular the Counterfeit Detection Systems (CDS). At the request of the Central Banks Counterfeit Deterrence Group (CBCDG), this software was added to scanner and printer drivers, as well as to image manipulation packages, in order to detect images of currency and prevent them from being processed.

I wrote a webpage on some experiments I ran on the CDS and gave a talk presenting the results of reverse engineering. Unsurprisingly this drew the attention of the involved parties, and while none of them contacted me directly, I was able to see them in my web logs. In September 2005, I first noticed Digimarc, who developed the CDS, followed a few hours later by the European Central Bank and the US Treasury (both CBCDG members), suggesting Digimarc tipped them off.

However none of these paid as much attention as the Bank of England (also a CBCDG member) who were looking at my pages several times a week. I didn’t notice them for a while due to their lack of reverse DNS, but in December I started paying attention. Not only was their persistence intriguing, but based on referrer logs their search queries indicated a particular interest in me, e.g. Project Dendros Steven Murdoch (Dendros is one of my research projects).

Perhaps they just found my work of interest, but in case they had concerns about my research (or me), I wanted to find out more. I didn’t know how to get in contact with the right person there, so instead I rigged my webpage to show visitors from either of the Bank of England’s two IP ranges a personalised message. On 9 February they found it, and here is what happened…

Continue reading Watching them watching me →

WEIS 2006

Privacy technology, Security economics

The Fifth Annual Workshop on the Economics of Information Security (WEIS) is coming to Cambridge on June 26-28. WEIS topics include the interaction of networks with crime and conflict; the economics of bugs; the dependability of open source and free software; liability and insurance; reputation; privacy; risk perception; the economics of DRM and trusted computing; the economics of trust; the return on security investment; and economic perspectives on spam. A preliminary program and accepted papers are available online.

Immediately following the conclusion of WEIS is the co-located Sixth Workshop on Privacy Enhancing Technologies, June 28-30. The last week of June is sure to be an exciting one in Cambridge.

Participation is open to all interested researchers, practitioners and policy-makers. Register by the end of the week for an early registration discount.

Workshop on Privacy in the Electronic Society (WPES 2006)

Call for papers, Privacy technology

I am on the program committee for the Workshop on Privacy in the Electronic Society (WPES), held in Alexandria, VA, USA on October 30, 2006. It is co-located with ACM Computer and Communication Security (CCS).

WPES discusses the problems of privacy in the global interconnected societies and possible solutions. We are looking for submissions from academia and industry presenting novel research on all theoretical and practical aspects of electronic privacy, as well as experimental studies of fielded systems.

We encourage submissions from other communities such as law and business that present these communities’ perspectives on technological issues.

The deadline for submissions is June 2, 2006.

Further details can be found in the call for participation [PDF].

Persec 2006 and Naccache on tapping mobile phones

Hardware & signals, Privacy technology

Over the past couple of months I attended about half a dozen events around the world (Brussels, Pisa (x3), Tokyo, Cambridge, York, Milan), often as invited speaker, but failed to mention them here. While I won’t promise that I will ever catch up with the reporting, let me at least start.

I was, with Ari Juels of RSA Labs, program chair of IEEE PerSec 2006, the security workshop of the larger PerCom conference, held in March 2006 in Pisa, Italy. I previously mentioned the rfid virus paper by Rieback et al when it got the (second) best paper award: that was the paper I found most enjoyable of the ones in the main track.

Ari and I invited David Naccache as the keynote speaker of our workshop. This was, if I may say so myself, an excellent move: for me, his talk was by far the most interesting part of the whole workshop and conference. Now a professor at the École Normale Supérieure in Paris, David was until recently a security expert at leading smartcard manufacturer Gemplus. Among other things, his talents allow him to help law enforcement agencies tap the bad guys’s cellphones, read the numbers in their phone books and find out where they have been.

His talk was very informative and entertaining, full of fascinating war stories such as the tricks used to steal covertly an expired session key from the phone of a suspect to decrypt a recorded phone call that had been intercepted earlier as cyphertext. The target was asleep in a hotel room, with his phone under recharge on his bed table, and the author and his agents were in the next room, doing their electronic warfare from across the wall. What do you do in a case like this? pretend to be the base station, reissue the old challenge so that the SIM generates the same session key, and then listen to the electromagnetic radiation from the pads of the SIM while the key is being transmitted to the handset via the SIM’s electric contacts. Brilliant. And just one in a rapid-fire sequence of other equally interesting real life stories.

David, like many of the other speakers at the workshop, has kindly allowed me to put up his paper and presentation slides on the workshop’s web site. It won’t be as good as his outstanding live talk, but you may still find it quite interesting.

On the same page you will also find two more papers by members of the Cambridge security group: one on multi-channel protocols by Ford-Long Wong and yours truly, and one attacking key distribution schemes in sensor networks by Tyler Moore.