Monthly Archives: August 2012

The rush to 'anonymised' data

Academic papers, Legal issues, News coverage, Politics, Privacy technology, Security economics, Security engineering

The Guardian has published an op-ed I wrote on the risks of anonymised medical records along with a news article on CPRD, a system that will make our medical records available for researchers from next month, albeit with the names and addresses removed.

The government has been pushing for this since last year, having appointed medical datamining enthusiast Tim Kelsey as its “transparency tsar”. There have been two consultations on how records should be anonymised, and how effective it could be; you can read our responses here and here (see also FIPR blog here). Anonymisation has long been known to be harder than it looks (and the Royal Society recently issued a authoritative report which said so). But getting civil servants to listen to X when the Prime Minister has declared for Not-X is harder still!

Despite promises that the anonymity mechanisms would be open for public scrutiny, CPRD refused a Freedom of Information request to disclose them, apparently fearing that disclosure would damage security. Yet research papers written using CPRD data will surely have to disclose how the data were manipulated. So the security mechanisms will become known, and yet researchers will become careless. I fear we can expect a lot more incidents like this one.

Analysis of FileVault 2 (Apple's full disk encryption)

Academic papers, Authentication, Cryptology, Useful software

With the launch of Mac OS X 10.7 (Lion), Apple has introduced a volume encryption mechanism known as FileVault 2.

During the past year Joachim Metz, Felix Grobert and I have been analysing this encryption mechanism. We have identified most of the components in FileVault 2’s architecture and we have also built an open source tool that can read volumes encrypted with FileVault 2. This tool can be useful to forensic investigators (who know the encryption password or recovery token) that need to recover some files from an encrypted volume but cannot trust or load the MAC OS that was used to encrypt the data. We have also made an analysis of the security of FileVault 2.

A few weeks ago we have made public this paper on eprint describing our work. The tool to recover data from encrypted volumes is available here.

Source Ports in ARF Reports

Security engineering

Long time readers may recall my posts from Jan 2010 about the need for security logging to include source port numbers — because of the growth of ‘Carrier Grade NAT’ (CGN) systems that share one IPv4 address between hundreds, possibly thousands, of users. These systems are widely used by the mobile companies and the ‘exhaustion‘ of IPv4 address space will lead to many other ISPs deploying them.

A key impact of CGNs is that if you want to trace back “who did that” you may need to have recorded not only an IP address and an accurate timestamp, but also to be able to provide the source port of the connection. Failure to provide the source port will mean that an ISP using CGN will not be able to do any tracing, because they will be unable to distinguish between hundreds of possible perpetrators. In June 2011 the IETF published an RFC (6302) which sets out chapter and verse for this issue and sets out Best Practice for security logging systems.

Earlier this year, at the M3AAWG meeting in San Francisco, I talked with the people who have developed the Abuse Reporting Format (ARF). The idea of ARF is that abuse reports will be in standard format — allowing the use of automation at both sender and receiver. Unfortunately ARF didn’t include a field for the source port….

… but it does now, because RFC 6692 has recently been published. My name is on it, but in reality all of the work on it that mattered was done by Murray Kucherawy who wrote the initial draft, who has tweaked the text to address working group concerns and who has guided it through the complexities of the IETF process. Thanks to Murray, the mechanisms for dealing with abuse have now become just a little bit better.