Monthly Archives: January 2013

CACM: A decade of OS access-control extensibility

Academic papers, Operating systems, Security engineering

Operating-system access control technology has undergone a remarkable transformation over the last fifteen years as appliance, embedded, and mobile device vendors transitioned from dedicated “embedded operating systems” to general-purpose ones — often based on open-source UNIX and Linux variants. Device vendors look to upstream operating system authors to provide the critical low-level software foundations for their products: network stacks, UI frameworks, application frameworks, etc. Increasingly, those expectations include security functionality — initially, features to prevent device bricking, but also to constrain potentially malicious code from third-party applications, which engages features from digital signatures to access control and sandboxing.

In a February 2013 Communications of the ACM article, A decade of OS access-control extensibility, I reflect on the central role of kernel access-control extensibility frameworks in supporting security localisation, the adaptation of operating-system security models to site-local or product-specific requirements. Similar to device driver stacks of the virtual file system (VFS), the goal is to allow third-party developers or integrators to extend base operating system security models without being exposed to unstable programming interfaces or the risks associated with less integrated techniques such as system-call interposition.

Case in point is the TrustedBSD MAC Framework, developed and deployed over the 2000s with support from DARPA and the US Navy, in collaboration with several industrial partners. In the article, I consider our original motivations, context, and design principles, but also track the transition process, which relied heavily on open source methodology and community, to a number of widely used products, including the open-source FreeBSD operating system, Apple’s Mac OS X and iOS operating systems, Juniper’s Junos router operating system, and nCircle’s IP360 product. I draw conclusions on things we got right (common infrastructure spanning models; tight integration with OS concurrency model) and wrong (omitting OS privilege model extension; not providing an application author identity model).

Throughout, the diversity of approaches and models suggests an argument for domain-specific policy models that respond to local tradeoffs between performance, functionality, complexity, and security, rather than a single policy model to rule them all. I also emphasise the importance of planning for long-term sustainability for research products — critical to adoption, especially via open source, but also frequently overlooked in academic research.

An open-access (and slightly extended) version of the article can be found on ACM Queue.

Dear ICO: disclose Sony's hash algorithm!

Authentication, Legal issues, News coverage

Today the UK Information Commissioner’s Office levied a record £250k fine against Sony over their 2011 Playstation Network breach in which 77 million passwords were stolen. Sony stated that they hashed the passwords, but provided no details. I was hoping that investigators would reveal what hash algorithm Sony used, and in particular if they salted and iterated the hash. Unfortunately, the ICO’s report failed to provide any such details:

The Commissioner is aware that the data controller made some efforts to protect account passwords, however the data controller failed to ensure that the Network Platform service provider kept up with technical developments. Therefore the means used would not, at the time of the attack, be deemed appropriate, given the technical resources available to the data controller.

Given how often I see password implementations use a single iteration of MD5 with no salt, I’d consider that to be the most likely interpretation. It’s inexcusable though for a 12-page report written at public expense to omit such basic technical details. As I said at the time of the Sony Breach, it’s important to update breach notification laws to require that password hashing details be disclosed in full. It makes a difference for users affected by the breach, and it might help motivate companies to get these basic security mechanics right.

Moore's Law won't kill passwords

Authentication, Security economics

Computers are getting exponentially faster, yet the human brain is constant! Surely password crackers will eventually beat human memory…

I’ve heard this fallacy repeated enough times, usually soon after the latest advance in hardware for password cracking hits the news, that I’d like to definitively debunk it. Password cracking is certainly getting faster. In my thesis I charted 20 years of password cracking improvements and found an increase of about 1,000 in the number of guesses per second per unit cost that could be achieved, almost exactly a Moore’s Law-style doubling every two years. The good news though is that password hash functions can (and should) co-evolve to get proportionately costlier to evaluate over time. This is a classic arms race and keeping pace simply requires regularly increasing the number of iterations in a password hash. We can even improve against password cracking over time using memory-bound functions, because memory speeds aren’t increasing nearly as quickly and are harder to parallellise. The scrypt() key derivation function is a good implementation of a memory-bound password hash and every high security application should be using it or something similar.

The downside of this arms race is that password hashing will never get any cheaper to deploy (even in inflation-adjusted terms). Hashing a password must be as slow and costly in real terms 20 years from now or else security will be lower. Moore’s Law will never reduce the expense of running an authentication system because security depends on this expense. It also needs to be a non-negligible expense. Achieving any real security requires that password verification take on the order of hundreds of milliseconds or even whole seconds. Unfortunately this hasn’t been the experience of the past 20 years. MD5 was launched over 20 years ago and is still the most common implementation I see in the wild, though it’s gone from being relatively expensive to evaluate to extremely cheap. Moore’s Law has indeed broken MD5 as a password hash and no serious application should still use it. Human memory isn’t more of a problem today than it used to be though. The problem is that we’ve chosen to let password verification become too cheap.

Privacy considered harmful?

Legal issues, News coverage, Politics

The government has once again returned to the vision of giving each of us an electronic health record shared throughout the NHS. This is about the fourth time in twenty years yet its ferocity has taken doctors by surprise.

Seventeen years ago, I was advising the BMA on safety and privacy, and we explained patiently why this was a bad idea. The next government went ahead anyway, which led predictably to the disaster of NPfIT. Nonetheless enough central systems were got working to seriously undermine privacy. Colleagues and I wrote the Database State report on the dangers of such systems; its was adopted as Lib Dem policy and aspects were adopted by the Conservatives too. That did lead to the abandonment of the ContactPoint children’s database but there was a rapid u-turn on health privacy after the election.

The big pharma lobbyists got their way after they got health IT lobbyist Tim Kelsey appointed as Cameron’s privacy tsar and it’s all been downhill from there. The minister says we have an opt-out; but no-one seems to have told him that under GPs will in future be compelled to upload a lot of information about us through a system called GPES if they want to be paid (they had an opt-out but it’s being withdrawn from April). And you can’t even register under a false name any more unless you use a stolen passport.

Yet more banking industry censorship

Banking security, Cryptology, Internet censorship, Legal issues, News coverage, Protocols, Security economics, Security engineering

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).

Interviews on the clean-slate design argument

News coverage, Operating systems, Processors, Security engineering

Over the past two years, Peter G. Neumann and I, along with a host of collaborators at SRI International and the University of Cambridge Computer Laboratory, have been pursuing CTSRD, a joint computer-security research project exploring fundamental revisions to CPU design, operating systems, and application program structure. Recently we’ve been talking about the social, economic, and technical context for that work in a series of media interviews, including one with ACM Queue on research into the hardware-software interface posted previously.

A key aspect to our argument is that the computer industry has been pursuing a strategy of hill climbing with respect to security; if we were willing to take a step back and revisit some of our more fundamental design choices, learning from longer-term security research over the last forty years, then we might be able to break aspects of the asymmetry driving the current arms race between attackers and defenders. This clean-slate argument doesn’t mean we need to throw everything away, but does suggest that more radical change is required than is being widely considered, as we explore in two further interviews: