The announcement is of course Good News — because once the PCeU is up and running next Spring, it should plug (to the limited extent that £2 million a year can plug) the “level 2″ eCrime gap that I’ve written about before. viz: that SOCA tackles “serious and organised crime” (level 3), your local police force tackles local villains (level 1), but if criminals operate outside their force’s area — and on the Internet this is more likely than not — yet they don’t meet SOCA’s threshold, then who is there to deal with them?

In particular, the PCeU is envisaged to be the unit that deals with the intelligence packages coming from the City of London Fraud Squad’s new online Fraud Reporting website (once intended to launch in November 2008, now scheduled for Summer 2009).

Of course everyone expects the website to generate more reports of eCrime than could ever be dealt with (even with much more money), so the effectiveness of the PCeU in dealing with eCriminality will depend upon their prioritisation criteria, and how carefully they select the cases they tackle.

Nevertheless, although the news this week shows that the Home Office have finally understood the need to fund more ePolicing, I don’t think that they are thinking about the problem in a sufficiently global context.

A little history lesson might be in order to explain why.

Back in 1930’s, Bonnie and Clyde and other US bank robbers were using the new-fangled automobile to flee across state lines — creating jurisdictional problems as a result. The US solution was to make bank robbery (along with auto-theft and other related offences) into federal offences rather keeping them as state-specific infractions. In particular this meant that the FBI could provide federal level policing (tracking down and killing John Dillinger for example).

We have the same jurisdictional issues dealing with cyberspace, with criminals in one country fleecing consumers in another while using systems hosted in a third. The Convention on Cybercrime addresses part of the problem by trying to ensure international consistency where eLaws are specifically needed (which of course is only the case for small parts of eCriminality, fraud is fraud whether eEnabled or not). However, there is limited inter-jurisdictional co-ordination for eCrime investigations — for example Interpol (often incorrectly perceived to be international police force) merely keeps a large database and passes faxes from one place to another.

In practice, most cross-border investigations are done as “joint operations” and the jointness is usually very limited — one force does all the legwork and a liaison officer in the other country deals with local paperwork. There’s usually a quid pro quo element to these joint operations, for budgeting reasons if no other.

What isn’t happening, or at least only in a handful of very specialised areas, is any international co-operation in setting priorities or selecting cases to pursue. Every country is doing its own thing about eCrime, and there’s a widespread impression that any criminal who can operate from “across the state line” is essentially immune from serious investigation.

We identified this problem last year when we (Ross Anderson, Rainer Böhme, Tyler Moore and myself) wrote a report on Security Economics and the Internal Market for ENISA. It’s not an easy one to fix whilst politicians (and populaces) are unwilling to see “foreign” police officers operating in their country, and the establishment of a truly international “cyber police force” seems equally unlikely.

Our policy proposal to tackle the issue harks back to WWII’s SHAEF, which has morphed into similar arrangements within NATO. In essence liaison officers from multiple forces would sit around a single table, working with a central coordinator, to set policy and decide which investigations to pursue. They would then communicate back to their own countries, who have specifically budgeted to provide appropriate assistance. So it’s very like “joint operations”, but the scheme is multi-laterial, and has a true command and control function in the centre — who will quickly learn to shy away from politically sensitive topics and make a real impact on eCriminality.

To summarise then, a welcome to the Home Office for finally finding a small amount of funding for some country-wide ePolicing; but it’s well past time to be working on world-wide initiatives.

Here's the story. Every Oyster card has a radio-frequency identification chip that communicates with readers mounted on the ticket barrier. That chip, the "Mifare Classic" chip, is used in hundreds of other transport systems as well — Boston, Los Angeles, Brisbane, Oslo, Amsterdam, Taipei, Shanghai, Rio de Janeiro — and as an access pass in thousands of companies, schools, hospitals, and government buildings around Britain and the rest of the world.

The security of Mifare Classic is terrible. This is not an exaggeration; it's kindergarten cryptography. Anyone with any security experience would be embarrassed to put his name to the design. NXP attempted to deal with this embarrassment by keeping the design secret.

The group that broke Mifare Classic is from Radboud University Nijmegen in the Netherlands. They demonstrated the attack by riding the Underground for free, and by breaking into a building. Their two papers (one is already online) will be published at two conferences this autumn.

The second paper is the one that NXP sued over. They called disclosure of the attack "irresponsible," warned that it will cause "immense damages," and claimed that it "will jeopardize the security of assets protected with systems incorporating the Mifare IC." The Dutch court would have none of it: "Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings."

Exactly right. More generally, the notion that secrecy supports security is inherently flawed. Whenever you see an organization claiming that design secrecy is necessary for security — in ID cards, in voting machines, in airport security — it invariably means that its security is lousy and it has no choice but to hide it. Any competent cryptographer would have designed Mifare's security with an open and public design.

Secrecy is fragile. Mifare's security was based on the belief that no one would discover how it worked; that's why NXP had to muzzle the Dutch researchers. But that's just wrong. Reverse-engineering isn't hard. Other researchers had already exposed Mifare's lousy security. A Chinese company even sells a compatible chip. Is there any doubt that the bad guys already know about this, or will soon enough?

Publication of this attack might be expensive for NXP and its customers, but it's good for security overall. Companies will only design security as good as their customers know to ask for. NXP's security was so bad because customers didn't know how to evaluate security: either they don't know what questions to ask, or didn't know enough to distrust the marketing answers they were given. This court ruling encourages companies to build security properly rather than relying on shoddy design and secrecy, and discourages them from promising security based on their ability to threaten researchers.

It's unclear how this break will affect Transport for London. Cloning takes only a few seconds, and the thief only has to brush up against someone carrying a legitimate Oyster card. But it requires an RFID reader and a small piece of software which, while feasible for a techie, are too complicated for the average fare dodger. The police are likely to quickly arrest anyone who tries to sell cloned cards on any scale. TfL promises to turn off any cloned cards within 24 hours, but that will hurt the innocent victim who had his card cloned more than the thief.

The vulnerability is far more serious to the companies that use Mifare Classic as an access pass. It would be very interesting to know how NXP presented the system's security to them.

And while these attacks only pertain to the Mifare Classic chip, it makes me suspicious of the entire product line. NXP sells a more secure chip and has another on the way, but given the number of basic cryptography mistakes NXP made with Mifare Classic, one has to wonder whether the "more secure" versions will be sufficiently so.

This essay originally appeared in the Guardian.

This limits the attack since in many cases TCP timestamps may be unavailable. In particular, Tor hidden services operate at the TCP layer, stripping all TCP and IP headers. If an attacker wants to estimate clock skew over the hidden service channel, the only directly available clock source may be the 1 Hz HTTP timestamp. The quantization noise in this case is three orders of magnitude above the TCP timestamp case, making the approach I used in the paper effectively infeasible.

While visiting Cambridge in summer 2007, Sebastian Zander developed an improved clock skew measurement technique which would dramatically reduce the noise of clock-skew measurements from low-frequency clocks. The basic idea, shown below, is to only request timestamps very close to a clock transition, where the quantization noise is lowest. This requires the attacker to firstly lock-on to the phase of the clock, then keep tracking it even when measurements are distorted by network jitter.

Sebastian and I wrote a paper — An Improved Clock-skew Measurement Technique for Revealing Hidden Services — describing this technique, and showing results from testing it on a Tor hidden service installed on PlanetLab. The measurements show a large improvement over the original paper, with two orders of magnitude lower noise for low-frequency clocks (like the HTTP case). This approach will allow previous attacks to be executed faster, and make previously infeasible attacks possible.

The paper will be presented at the USENIX Security Symposium, San Jose, CA, US, 28 July – 1 August 2008.

Tests by heise Security show that four of the six services tested were vulnerable to attack.

While all of the tested systems encrypt communication with the backup server using SSL, external attackers can sniff the access code as plain text by acting as a man-in-the-middle (MITM) if the locally installed backup software does not perform sufficiently rigorous checks on the authenticity of the server’s certificates. In the vulnerable systems, we were able to hijack the connection from the client software to the backup servers.

Four of six may not be a large test sample, but it does raise concerns about trust between customers and their service providers. If you’re providing or purchasing this kind of service, you might want to look into it closely to make sure your data is secure.

One of the arguments I’ve heard folks use to dismiss the notion of a risk-based approach to security is that it’s been tried and failed.  The argument goes on to claim that it isn’t possible to get appropriate funding for security because management just doesn’t “get it”.  And, while I agree that many (most?) past attempts at risk-based security have struggled, I’d submit that it was because the methods used didn’t address risk effectively.  They often focused solely on worst-case outcomes (which is the Chicken Little problem), didn’t apply any rigor in determining risk, simply focused on vulnerability (but called it “risk”), or treated the problem as a possibility issue versus a probability issue. 

Of course, the argument about funding begs the question of what constitutes “appropriate funding”.  It’s naive (or arrogant) to believe that I — as an information security professional — am in a position to understand the incredible mix of business issues that determine the right risk-balance for an organization.  Running a business requires weighing the various risk-domains management faces (investment, insurance, product, market, security, etc.) as well as complex value propositions in light of the organization’s objectives and limited resources.  And, while it’s imperative that information security professionals seek to understand the business side of the equation, we are never going to have the same breadth and depth of vision into the organization’s unique mix of business issues that executive management has.  Combine that with the fact that it isn’t our risk tolerance that matters, and it should be crystal clear that complaints of being “underfunded” have to be cast in the light of “Compared to what?”.  Compared to what we think it ought to be?  Compared to some industry baseline of questionable applicability to our organization?

Of course, I struggled to get management support for years.  I tried leveraging fear, uncertainty, and doubt.  I also tried the old “You have to do it because it’s best practice” card.  And although both of these can work for awhile, at the end of the day, management’s perspective will likely be that you’re paranoid and you lack perspective about the nature of running a business.  I’ve come to the conclusion that if I believe I’m underfunded, then it’s likely:

• I haven’t done a good job of communicating risk to the business, 
• I don’t sufficiently understand the risk tolerance of the organization’s leadership, and/or
• I don’t understand the mix of competing risk issues, resource limitations, or business objectives.  

It’s my responsibility to see that I’m not underfunded by providing high quality (unbiased) risk information to management.  If I do that, then I can expect to receive an appropriate level of funding given the other business considerations management faces and their risk tolerance.  The funding may be less than I’d like given my risk tolerance, but that’s a personal problem. 

Frankly, since taking a risk-based approach to my job, I’ve had very little difficulty getting management support for the stuff that matters most.

Anyway, as a security professional you have probably heard of last year’s massive data theft involving several high profile Formula One teams like Ferrari, McLaren, and Renault. What you might have not heard is how the technical data got stolen: Well, in the ultra sophisticated and technologically advanced world of Formula One racing, design plans and test results were simply copied to a bunch of floppy disks. Yes, floppy disks - those early versions of portable media devices that never really made it into the new millennium!

Having recently had a chance to chat with a CISO from a European F1 team, I can assure you that data theft via traditional data loss channels like email, IM, and FTP, as well as endpoint activities like copying to USBs, CD-Roms, external hard drives, and yes, floppy disks are now sufficiently safeguarded with the help of modern data loss prevention (DLP) solutions. F1 teams simply cannot afford to lose critical data because even small data pieces can mean the difference between winning and losing races. And likewise, merely having stolen information in your network (e.g., your competition’s construction plans or results from aerodynamic testing brought along by a newly hired engineer), can – under the tight regulatory rules of the FIA – lead to anything from hefty fines to (more likely!) exclusion from races, i.e., put you out of business…

The moral of the story? Please manage and safeguard all possible data theft channels and know what data resides in your network! That is, unless you want to risk losing your next data security race.