The European Court of Justice decision in the Google case will have implications way beyond search engines. Regular readers of this blog will recall stories of banks hounding innocent people for money following payment disputes, and a favourite trick is to blacklist people with credit reference agencies, even while disputes are still in progress (or even after the bank has actually lost a court case). In the past, the Information Commissioner refused to do anything about this abuse, claiming that it’s the bank which is the data controller, not the credit agency. The court now confirms that this view was quite wrong. I have therefore written to the Information Commissioner inviting him to acknowledge this and to withdraw the guidance issued to the credit reference agencies by his predecessor.
I wonder what other information intermediaries will now have to revise their business models?
Bank names are so tricksy — they all have similar words in them… and so it’s common to see phishing feeds with slightly the wrong brand identified as being impersonated.
However, this story is about how something the way around has happened, in that AnonGhost, a hacker group, believe that they’ve defaced “Yorkshire Bank, one of the largest United Kingdom bank” and there’s some boasting about this to be found at http://www.p0ison.com/ybs-bank-got-hacked-by-team-anonghost/.
However, it rather looks to me as if they’ve hacked an imitation bank instead! A rather less glorious exploit from the point of view of potential admirers.
Continue reading Ghosts of Banking Past
I will be trying to liveblog Financial Cryptography 2014. I just gave a keynote talk entitled “EMV – Why Payment Systems Fail” summarising our last decade’s research on what goes wrong with Chip and PIN. There will be a paper on this out in a few months; meanwhile here’s the slides and here’s our page of papers on bank security.
The sessions of refereed papers will be blogged in comments to this post.
Today we release a paper on security protocols and evidence which analyses why dispute resolution mechanisms in electronic systems often don’t work very well. On this blog we’ve noted many many problems with EMV (Chip and PIN), as well as other systems from curfew tags to digital tachographs. Time and again we find that electronic systems are truly awful for courts to deal with. Why?
The main reason, we observed, is that their dispute resolution aspects were never properly designed, built and tested. The firms that delivered the main production systems assumed, or hoped, that because some audit data were available, lawyers would be able to use them somehow.
As you’d expect, all sorts of things go wrong. We derive some principles, and show how these are also violated by new systems ranging from phone banking through overlay payments to Bitcoin. We also propose some enhancements to the EMV protocol which would make it easier to resolve disputes over Chip and PIN transactions.
Update (2013-03-07): This post was mentioned on Bruce Schneier’s blog, and this is some good discussion there.
Update (2014-03-03): The slides for the presentation at Financial Cryptography are now online.
Today we’re presenting a new side-channel attack in PIN Skimmer: Inferring PINs Through The Camera and Microphone at SPSM 2013. We found that software on your smartphone can work out what PIN you’re entering by watching your face through the camera and listening for the clicks as you type. Previous researchers had shown how to work out PINs using the gyro and accelerometer; we found that the camera works about as well. We watch how your face appears to move as you jiggle your phone by typing.
There are implications for the design of electronic wallets using mechanisms such as Trustzone which enable some apps to run in a more secure sandbox. Such systems try to prevent sensitive data such as bank credentials being stolen by malware. Our work shows it’s not enough for your electronic wallet software to grab hold of the screen, the accelerometers and the gyro; you’d better lock down the video camera, and the still camera too while you’re at it. (Our attack can use the still camera in burst mode.)
We suggest ways in which mobile phone operating systems might mitigate the risks. Meanwhile, if you’re developing payment apps, you’d better be aware that these risks exist.
With some delay here is the second and final part on our impressions of David Birch’s Tomorrow’s Transactions Forum (TTF13), which we attended thanks to Dave’s generosity (See full agenda and PowerPoint presentations here). See part 1 here.
NOTE: Although written in first person, what follows results from a combination of Laurent Simon’s and my notes.
The theme of day 2 at TTF13 was social inclusion. The kick off question was “How to develop tools to help people deal with money?” (people with no financial culture and based on a transactional account).
This was followed by presentations on “Comic Relief” (the day before ‘the big day’), “Universal Credit” and expert panel on financial inclusion.
Continue reading Current issues in payments (part 2)
In this first of a two or three part instalment. In them Laurent Simon and I comment on our impressions of David Birch’s Tomorrow’s Transactions Forum, which we attended thanks to Dave’s generosity.
NOTE: Although written in first person, what follows results from a combination of Laurent’s and my notes.
This was a two day event for a handful of guests to foster communication and networking. I appreciated the format.
After a brief introduction, the first day kicked off with my ever growing presentation on the origins of the cashless society (you can see it here ).
The following act was Tillman Bruett (UNCDF), who was involved in the drafting of The journey towards cash-lite (at least so say the acknowledgements).
Continue reading Current issues in payments (part 1)
Today, the UK Cards Association (UKCA) published their summary of bank fraud for 2012. This provides an important insight into banking fraud, and the level of detail which the UK banks provide is very welcome. The UKCA figures go back to 2007, but I’ve collected the figures from previous releases going back to 2004. This data reveals some interesting trends, especially related to the deployment of new security technologies.
larger version (PDF)
The overall fraud losses in 2012 are £475.3m, up 11% from the 2011 level, but for the purposes of comparison it is helpful to exclude the losses from phone banking since these figures were only available since 2009 (and are only 2.7% of the total). If we look at the resulting trend in total fraud (£462.7m) we can see that while there was an increase in 2012, that is from a starting position of a 10-year low in 2011 so isn’t a reason to panic. We are still far from the peak in 2008 of £704.3m.
[You may have noticed the miniaturised graph in line with the text above, which an an example of a sparkline and I’ll be using these throughout this post to more clearly show trends in the data. Each graph shows the change in a single value over the 2004–2012 period, and is followed by the figure for 2012 in red.]
However, there is a large omission in the UKCA data – it records losses of the banks and merchants but not customers. If a customer is a victim of fraud, but the bank refuses to refund them (because the bank claims the customer was negligent), we won’t see it in these figures – as confirmed by a UKCA representative in an interview on BBC Radio Merseyside on 2007-02-19. We don’t know how much is missing from the fraud statistics as a result, but from the Financial Services Authority statistics we can see that there were 483,666 complaints in the first half of 2012 against firms regarding disputed charges, so the sums in question could be substantial. But despite this limitation, the statistics from the UKCA are valuable, especially in that it gives a break down of fraud by type.
Continue reading UK bank fraud up by 11% in 2012, but how much do customers lose?
Research in the Security Group has uncovered various flaws in systems, despite them being certified as secure. Sometimes the certification criteria have been inadequate and sometimes the certification process has been subverted. Not only do these failures affect the owners of the system but when evidence of certification comes up in court, the impact can be much wider.
There’s a variety of approaches to certification, ranging from extremely generic (such as Common Criteria) to highly specific (such as EMV), but all are (at least partially) descendants of a report by Willis H. Ware – “Security Controls for Computer Systems”. There’s much that can be learned from this report, particularly the rationale for why certification systems are set up as the way they are. The differences between how Ware envisaged certification and how certification is now performed is also informative, whether these differences are for good or for ill.
Along with Mike Bond and Ross Anderson, I have written an article for the “Lost Treasures” edition of IEEE Security & Privacy where we discuss what can be learned, about how today’s certifications work and should work, from the Ware report. In particular, we explore how the failure to follow the recommendations in the Ware report can explain why flaws in certified banking systems were not detected earlier. Our article, “How Certification Systems Fail: Lessons from the Ware Report” is available open-access in the version submitted to the IEEE. The edited version, as appearing in the print edition (IEEE Security & Privacy, volume 10, issue 6, pages 40–44, Nov‐Dec 2012. DOI:10.1109/MSP.2012.89) is only available to IEEE subscribers.
Yesterday, banking security vendor Thales sent this DMCA takedown request to John Young who runs the excellent Cryptome archive. Thales want him to remove an equipment manual that has been online since 2003 and which was valuable raw material in research we did on API security.
Banks use hardware security modules (HSMs) to manage the cryptographic keys and PINs used to authenticate bank card transactions. These used to be thought to be secure. But their application programming interfaces (APIs) had become unmanageably complex, and in the early 2000s Mike Bond, Jolyon Clulow and I found that by sending sequences of commands to the machine that its designers hadn’t anticipated, it was often possible to break the device spectacularly. This became a thriving field of security research.
But while API security has been a goldmine for security researchers, it’s been an embarrassment for the industry, in which Thales is one of two dominant players. Hence the attempt to close down our mine. As you’d expect, the smaller firms in the industry, such as Utimaco, would prefer HSM APIs to be open (indeed, Utimaco sent two senior people to a Dagstuhl workshop on APIs that we held a couple of months ago). Even more ironically, Thales’s HSM business used to be the Cambridge startup nCipher, which helped our research by giving us samples of their competitors’ products to break.
If this case ever comes to court, the judge might perhaps consider the Lexmark case. Lexmark sued Static Control Components (SCC) for DMCA infringement in order to curtail competition. The court found this abusive and threw out the case. I am not a lawyer, and John Young must clearly take advice. However this particular case of internet censorship serves no public interest (as with previous attempts by the banking industry to censor security research).