Two years ago, Hyoungshick Kim, Jun Ho Huh and I wrote a paper On the Security of Internet banking in South Korea in which we discussed an IT security policy that had gone horribly wrong. The Government of Korea had tried in 1998 to secure electronic commerce by getting all the banks to use an officially-approved AciveX plugin, effectively locking most Koreans into IE. We argued in 2010 that this provided less security than it seemed, and imposed high usability and compatibility costs. Hyoungshick presented our paper at a special conference, and the government withdrew the ActiveX mandate.

It’s now apparent that the problem is still there. The bureaucracy created a procedure to approve alternative technologies, and (surprise) still hasn’t approved any. Korean web businesses remain trapped in the bubble, and fall farther and farther behind. This may well come to be seen as a warning to other governments to adopt true open standards, if they want to avoid a similar fate. The Cabinet Office should take note – and don’t forget to respond to their consultation!

For the past 4 days Cambridge has been hosting Eurocrypt 2012.

There were many talks, probably interesting, but I will only comment on 3 talks given by Adi Shamir, 1 during the official conference and 2 during the rump session.
Among the other sessions I mention that the best paper was given to this paper by Antoine Joux and Vanessa Vitse for the enhancement of index calculus to break elliptic curves.

Official Talk: Minimalism in cryptography, the Even-Mansour scheme revisited

In this work, Adi et al. presented an analysis on the Even-Mansour scheme:

E(P) = F(P ⊕ K1) ⊕ K2

Such scheme, some times referred to as key whitening, is used in the DESX construction and in the AES-XTS mode of operation (just a few examples).

Adi et al. shown a new slide attack, called SLIDEX, which has been used to prove a tight bound on the security of the Even-Mansour scheme.

Even more, they show that using K1 = K2 you can achieve the same security.

Rump talk 1: security of multiple key encryption

Here Adi considered the case of encrypting data multiple times with multiple keys, as in 3DES:
data -> c1 = E_k1(data) ->  c2 = E_k2(c1) -> c3 = E_k3(c2) -> c4 = E_k3(c3) …. and so on.

The general approach to break a scheme where a key is used 2 times or 3 times (2DES, 3DES for e.g.) is the meet-in-the-middle attack, where you encrypt from one side and then decrypt from the other side, and by storing a table of the size of the key space (say n bits) you can eventually find the keys used in a scheme using only a few pairs of plaintext/ciphertext. For 2 keys such an attack would require 2^{n} time, for 3 keys 2^{2n}. Therefore some people may assume that increasing the number of keys by 1 (i.e. to use 4 keys) may increase the security of this scheme. This is in fact not true.

Adi shown that once we go beyond 3 keys (e.g. 4, 5, 6, etc…) the security only increases once every few keys. If you think of it, using 4 keys you can just apply the meet-in-the-middle attack in 2^{2n} time to the left 2 encryptions and also in 2^{2n} time to the right 2 decryptions. After this, he shown how to use the meet-in-the-middle attack to solve the knapsack problem and proposed the idea of using such an algorithm to solve other problems as well.

Rump talk 2: the cryptography of John Nash

Apparently John Nash, member of MIT during the 1950s, wrote some letters to the NSA in 1955 explaining the implications of computational complexity for security (this wasn’t known at the time).

John Nach also sent a proposal for an encryption scheme that is similar with today’s stream ciphers. However the NSA’s replied saying that the scheme didn’t match the security requirements of the US.
Adi Shamir and Ron Rivest then analysed the scheme and found that in the known plaintext model it would require something like 2^{sqrt(n)} time to break (which John Nach considered not to be a polynomial time, and therefore assumed would be secure).

The letters are now declassified. This blog also comments on the story.

On the first of April, the Sunday Times carried a story that the Home Secretary planned to expand the scope of the Regulation of Investigatory Powers Act. Some thought this was an April Fool, but no: security minister James Brokenshire confirmed the next day that it was for real. This led to much media coverage; here is a more detailed historical timeline.

There have been eight previous Scrambling for Safety conferences organised while the UK government was considering the RIP Act and the regulations that followed it. The goal is to bring together different stakeholders interested in surveillance policy for an open exchange of views. The conference is open to the public, but you have to register here.

Here is the programme and the event website.

Information is often an important asset and today’s information is commonly stored as digital data (bytes). We store this data in our computers local hard disks and in our laptops disks. Many organisations wish to keep the data stored in their computers and laptops confidential. Therefore a natural desire is that a stolen disk or laptop should not be readable by an external person (an attacker in general terms). For this reason we use encryption.

A hard disk is commonly logically organised in multiple sections, often referred to as either partitions or volumes. These volumes can be used for various purposes, and they are often structured according to a file system format (e.g. NTFS, FAT, HFS, etc.). It is possible to have a single disk with 3 volumes, where the first volume is formatted with NTFS and contains a Windows operating system, the second volume is formatted with EXT3 file system and contains an installation of a Linux distribution, while the third volume is formatted with FAT file system and only contains data (no operating system).

Volume encryption is a mechanism used to encrypt the contents of an entire volume. This is sometimes referred as “full disk encryption”, which is misleading, since a physical disk can actually contain multiple volumes, each encrypted independently.  However, since the term has become very popular, I will continue to refer to this kind of encryption as “full disk encryption” but the reader should keep the above distinction in mind.

There are several products that offer full disk encryption, e.g. PGP Whole Disk Encryption, TrueCrypt, Sophos SafeGuard, or Check Point FDE. Bitlocker is the full disk encryption integrated with the Windows OS and Apple has recently introduced FileVault 2 as full disk encryption from MAC OS X 10.7.

There are several limitations that affect the encryption of an entire disk. These have to do with 3 important aspects among others: a) encryption must be fast (a user should not notice any extra latency); b) the operating system is encrypted as well (so there must be some way of bootstrapping the decryption process when the computer boots)  c) the encryption mechanism should not reduce the available storage space noticeable (that is, we cannot use an extra block of data for every few encrypted blocks).

The following 3 papers explain in detail these limitations. Two of them relate to currently deployed full disk encryption systems.

Lest we remember: cold boot attacks on encryption keys. J. Halderman et al. Usenix Security Symposium 2008.

This paper explores the possibility of extracting encryption keys from memory (DRAM in particular). Full disk encryption uses a volume  key to encrypt and decrypt disk blocks. In order to allow a fast process the keys are stored in memory. Even more, the keys are expanded (e.g. for AES) and the round keys are also stored in memory (key expansion would introduce a considerable latency if this would need to be done for every block). Therefore a simple dump of the memory will contain the sensitive keys. The authors of this paper consider also the scenario in which a DRAM chip is extracted from the computer and measure the time after which the keys are still retrievable. Using the redundancy given by the expansion keys this time can be increased.

New methods in hard disk encryption. C Fruhwirth, Institute for Computer Languages, Theory and Logic, 2005.

This paper goes into the details of the encryption schemes that can be used for disk encryption and discusses many of the problems that are particular to this type of encryption. It details for example the many problems in using a common scheme such as CBC and also explains some techniques that can be used. The author has implemented some of the algorithms presented in LUKS (Linux Unified Key Setup).

AES-CBC + Elephant difusser: A disk encryption algorithm for Windows Vista. N Ferguson. Microsoft Corp. 2006.

This paper describes the encryption algorithm used in Bitlocker, the full disk encryption system available in Windows (since Vista). The paper comments on the limitations of existing encryption schemes and performance issues and details the solution adopted by Microsoft.

As an additional remark I point out that around 2007 a new mode of operation for AES, called AES-XTS, has been standardized:
http://grouper.ieee.org/groups/1619/email/pdf00086.pdf. This is a “tweakable” mode of encryption (based on Rogaway’s XEX – http://www.springerlink.com/content/1wp57yvu5du2ecwv/), which allows each block in a disk to be encrypted independently. This has major advantages over other encryption modes such as CBC and has already been adopted by Apple in their full disk encryption system: FileVault 2.

I have been waiting for this day for 17 years! Today, United States Patent 5,404,140 titled “Coding system” owned by Mitsubishi expires, 22 years after it was filed in Japan.

Why the excitement? Well, 17 years ago, I wrote JBIG-KIT, a free and open-source implementation of JBIG1, the image compression algorithm used in all modern fax machines. My software is about 4000 lines of code long (in C), and only one single “if” statement in it is covered by the above patent:

      if (s->a < lsz) { s->c += s->a; s->a = lsz; }

And sadly, there was no way to implement a JBIG1 encoder or decoder without using this patented line of code (in some form) while remaining compatible with all other JBIG1 implementations out there.

For the technically interested: JBIG1 uses an arithmetic coder that estimates the probability that the next pixel to be encoded is either black or white (taking into account 10 previously transmitted neighbour pixels). Arguably in the interest of saving a bit of RAM in hardware implementations, the standard does not use the simple arithmetic expression that estimates these pixel probabilities based on counts of how often a pixel has been black or white before in that context: p(next pixel is white) = (#white pixel so far + 1) / (#pixels so far + 1). Instead, it defines a finite-state machine that comes up with a cruder estimate, using just 7 bits to define 113 states, rather than actually counting pixels with 32-bit registers. IBM had a patent on that finite-state machine, which is really hardly more than an obfuscated counter. Then a Mitsubishi employee noticed that the crude IBM approximation sometimes ended up assigning to the “less probable pixel colour” a probability larger than 0.5, making it actually more probable. So they suggested the above if-statement to swap the probability estimates of the two colours in those rare cases, leading to a tiny improvement in coding efficiency.

Not only is the tiny improvement patented by Mitsubishi pretty trivial, it would also have been utterly unnecessary if IBM hadn’t first used in the standard a patented, but defect, finite state machine, rather than a simple counting process. But standards committees have little incentives to minimize the impact of patents on their products. On the contrary. The standardization of file formats and computer protocols turned in the late 1980s into a very nasty game: every participant is now mainly interested in squeezing as many of their patented ideas into the resulting standard as possible. The JBIG1 standard is a good example of a technology that could have been made much simpler and a bit more efficient if the authors hadn’t had to justify to their employers the time spent on developing the standard with the prospect that users of the standard would have to pay licence fees.

The underlying problem is compatibility. If I had to implement an image compression technique, I could have come up with something much simpler than JBIG1, which may have required slightly more RAM, but would have been much easier to understand and possibly even compress slightly better. However, the result would have been incompatible with what international standards bodies had already agreed would have to be implemented in every new fax machine on the planet.

I had once hoped that JBIG-KIT would help with the exchange of scanned documents on the Internet, facilitate online inter-library loan, and make paper archives more accessible to users all over the world. However, the impact was minimal: no web browser dared to directly support a standardized file format covered by 23 patents, the last of which expired today.

About 25 years ago, large IT research organizations discovered standards as a gold mine, a vehicle to force users to buy patent licenses, not because the technology is any good, but because it is required for compatibility. This is achieved by writing the standards very carefully such that there is no way to come up with a compatible implementation that does not require a patent license, an art that has been greatly perfected since. The IT standards landscape is now littered with golden patent monsters, whose complexity and use of exotic techniques is hardly justifiable by technical benefits, e.g. radio communications standards and storage formats. Even the utterly archaic MS-DOS VFAT file system used on every USB memory stick still makes its inventors money, not because it has any inherent benefits, but simply because its patent owner made sure that their market-dominant operating system lacked support for any of the many simpler and more elegant alternative file systems that support long filenames without requiring a patent licence.

Thanks to the perverse marriage of patents and the standardization of computer file formats and network protocols, patents have now the opposite effect of what they were originally introduced for. Patents were meant to protect investors, such that they could justify the often large investment necessary to introduce a new technology on the market. The idea was to encourage innovation. In the field of standardized file formats and computer protocols, patents are now the main hindrance. Ideas that require hardly any measurable investment to be invented or implemented (a single “if” statement in a program!) earn more than 20 years of government-guaranteed monopolistic protection.

There is a simple solution: amend patent legislation such that no patent licenses have to be obtained solely for the purpose of compatibility. No patent licence should be required by law if a technology is used solely to enable communication with another information-technology product. I believe this would eliminate instantly the enormous threat that patents now pose to the progress of standardization and improved interoperability in our networked information society, without imposing unrealistic expectations on the process of examining and granting patents.

The practice of limiting the protection of a right holder to enable competitors “to achieve the interoperability of an indepen­dently created program with other programs” (EU Directive 2009/24/EC) has already been common practice in copyright legislation worldwide for many years.

It is time that we fix patent law in just the same way!

I’ve just given a talk on Risk and privacy implications of consumer payment innovation (slides) at the Federal Reserve Bank’s payments conference. There are many more attendees this year; who’d have believed that payment systems would ever become sexy? Yet there’s a lot of innovation, and regulators are starting to wonder. Payment systems now contain many non-bank players, from insiders like First Data, FICO and Experian to service firms like PayPal and Google. I describe a number of competitive developments and argue that although fraud may increase, so will welfare, so there’s no reason to panic. For now, bank supervisors should work on collecting better fraud statistics, so that if there ever is a crisis the response can be well-informed.

Nominations are invited for the 2012 PET Award by 31 March 2012.

The PET Award is presented annually to researchers who have made an outstanding contribution to the theory, design, implementation, or deployment of privacy enhancing technology. It is awarded at the annual Privacy Enhancing Technologies Symposium (PETS).

The PET Award carries a prize of 3000 USD thanks to the generous support of Microsoft. The crystal prize itself is offered by the Office of the Information and Privacy Commissioner of Ontario, Canada.

Any paper by any author written in the area of privacy enhancing technologies is eligible for nomination. However, the paper must have appeared in a refereed journal, conference, or workshop with proceedings published in the period from 1 June 2010 until 31 March 2012.

For eligibility requirements, refer to the award rules.

Anyone can nominate a paper by sending an email message containing the following to award-chairs12@petsymposium.org:

• Paper title
• Author(s)
• Author(s) contact information
• Publication venue and full reference
• Link to an available online version of the paper
• A nomination statement of no more than 500 words.

All nominations must be submitted by 31 March 2012. The Award Committee will select one or two winners among the nominations received. Winners must be present at the 2012 PET Symposium in order to receive the Award. This requirement can be waived only at the discretion of the PET Advisory board.

More information about the PET award (including past winners) is see the award website.

We are pleased to announce a job opening at the University of Cambridge Computer Laboratory for a post-doctoral researcher working in the areas of security, operating systems, and computer architecture.

Research Associate in compiler-assisted instrumentation of operating system kernels
University of Cambridge – Faculty of Computer Science and Technology
Salary: £27,578-£35,938 pa

The funds for this post are available for up to two years:

We are seeking a Post-doctoral Research Associate to join the CTSRD and MRC2 projects, which are investigating fundamental revisions to CPU architecture, operating system (OS), programming language, and networking structures in support of computer security. The two projects are collaborations between the University of Cambridge and SRI International, and part of the DARPA CRASH and MRC research programmes on clean-slate computer system design.

This position will be an integral part of an international team of researchers spanning multiple institutions across academia and industry. The successful candidate will contribute to low-level aspects of system software: compilers, language run-times, and OS kernels. Responsibilities will include researching the application of novel dynamic instrumentation techniques to C-language operating systems and applications, including adaptation of the FreeBSD kernel and LLVM compiler suite, and evaluation of the resulting system.

An ideal candidate will hold (or be close to finishing) a PhD in Computer Science, or have similar, with a strong background in low-level system software development, which should include at least of one of strong kernel development experience (FreeBSD preferred; Linux acceptable), or compiler internals experience (LLVM preferred; gcc acceptable). Strong experience with the C programming language is critical. A strong background in computer security is also recommended.

Candidates must be able to provide evidence of relevant work demonstrated by a research publication track record or industrial experience. Good interpersonal and organisational skills and the ability to work in a team are also essential. This post is intended to be filled as soon as practically possible after the closing date.

Applications should include:

• CV
• Brief statement of the particular contribution you would make to the project
• A completed form CHRIS6

Applications should be sent, preferably by email, to personnel-admin@cl.cam.ac.uk. Postal Address: Personnel-Admin, University of Cambridge, Computer Laboratory, 15 JJ Thomson Avenue, Cambridge, CB3 0FD

Quote Reference: NR14931
Closing Date: 23 April 2012
The University values diversity and is committed to equality of opportunity.

Mention the phrase “binary reverse engineering” or “binary analysis” and it often conjures up an image of software pirates or hacking groups. However, there are practical reasons for doing analysis on machine code. For instance, machines don’t run source code, they run machine code – how do we know it’s running correctly? Malware doesn’t usually come with source code (but they are known to leak on occasion); How do we protect our software from discovered vulnerabilities if we’re unable to re-compile the program from the original source code? For three paper Thursday this week, my contribution is to highlight three representative security applications of binary analysis, namely software testing, malware analysis and software protection.

If the same input given to two different implementations of the same protocol specification gives rise to a deviation in the output state, then an implementation error has been found.

This paper is an interesting read in my opinion because it took a non-obvious twist to the software verification problem. Given a Hoare triple {P}C_i{Q}, where P is the pre-condition, C_i, i=1,2 are the two implementations, and post-condition Q, we want to compute the weakest pre-condition f_i = wp(C_i, Q). Function f_i is a boolean formula over the input space of C_i such that if f_i(x) = true, then Q is true. Then a deviation is likely to occur when either !f₁(x) && f₂(x) or f₁(x) && !f₂(x) is satisfiable. Computing the weakest pre-condition in real programs is challenging because it can easily result in a formula that is too large to solve. The paper dealt with this issue by keeping to a single execution path, making only input variables symbolic and by keeping Q simple. The authors then showed that even with these simplifications, they found several bugs, including one in the Miniweb HTTP server that assumed the first character of the URI to be a slash even when it was not. Another interesting application of this technique was to generate implementation fingerprints based on these deviations.

The goal is to extract stand-alone code fragments, for example an encryption routine E(), and derive its inversion, E^-1(), automatically from malware.

The idea is neat, and the problem is a practical one for malware analysts. The initial step is a manual one. Given a log of the malware’s behaviour, the analyst specifies the data of interest (in this case a particular API call), and the Inspector takes care of the rest. There are at least two challenges in this task. Firstly, extracting the code, or gadget, is challenging. Given a target location T, Inspector has to perform a program slice on T. In the worst case, this leads to all instructions being included in the slice. Inspector deals with this issue using various heuristics to determine suitable end-points. Secondly, and in my opinion the more difficult problem, creating a gadget replayer is non-trivial since its supposed to run on bare metal. This requires that memory buffers be relocated, all errors to be properly handled and the API call interface to be carefully configured so that its execution stays true to the original but yet is contained safely. To invert a function E(), Inspector uses a brute-force approach on a sub-set of the output space. It was slightly disappointing that the authors did not use SAT/SMT solvers for this task, although it was mentioned as a possible extension.

Data structures can be identified via dynamic memory access patterns and retro-fitted with buffer overflow protection

The problem addressed in this paper is recovering variables types from machine code, specifically locally defined data structures. The key insight is that even though the bytes on the stack look anonymous and the code is highly optimised, the way they are accessed provides a means to infer their structure. If a memory buffer is accessed in strides of a word size, then we may infer that the buffer contains a word-sized array. If the buffer has more than one possible stride pattern, then the “least common pattern” heuristic is used. However, sometimes the structure is not accessed all at once, and Howard makes use of the fact that the accesses share a common base pointer. Howard does per-execution analysis and relies on KLEE to generate a comprehensive set of test input. The buffer protection mechanism is similar to that of WIT – all buffers are given a colour. When a pointer is initialised to the buffer, it is assigned that colour. Whenever it does a dereferenced write, a check is made to ensure that the pointer and buffer colours coincide. On the whole, this paper addresses a difficult problem with a nice solution and rounds it off with a practical security application.