The "Oyster card" used on the London Tube was at issue in the Dutch case, and a similar fare card used on the Boston "T" was the center of the U.S. case. The Dutch court got it right, and the American court, in Boston, got it wrong from the start -- despite facing an open-and-shut case of First Amendment prior restraint.

The U.S. court has since seen the error of its ways -- but the damage is done. The MIT security researchers who were prepared to discuss their Boston findings at the DefCon security conference were prevented from giving their talk.

The ethics of full disclosure are intimately familiar to those of us in the computer-security field. Before full disclosure became the norm, researchers would quietly disclose vulnerabilities to the vendors -- who would routinely ignore them. Sometimes vendors would even threaten researchers with legal action if they disclosed the vulnerabilities.

Later on, researchers started disclosing the existence of a vulnerability but not the details. Vendors responded by denying the security holes' existence, or calling them just theoretical. It wasn't until full disclosure became the norm that vendors began consistently fixing vulnerabilities quickly. Now that vendors routinely patch vulnerabilities, researchers generally give them advance notice to allow them to patch their systems before the vulnerability is published. But even with this "responsible disclosure" protocol, it's the threat of disclosure that motivates them to patch their systems. Full disclosure is the mechanism (.pdf) by which computer security improves.

Outside of computer security, secrecy is much more the norm. Some security communities, like locksmiths, behave much like medieval guilds, divulging the secrets of their profession only to those within it. These communities hate open research, and have responded with surprising vitriol to researchers who have found serious vulnerabilities in bicycle locks, combination safes (.pdf), master-key systems and many other security devices.

Researchers have received a similar reaction from other communities more used to secrecy than openness. Researchers -- sometimes young students -- who discovered and published flaws in copyright-protection schemes, voting-machine security and now wireless access cards have all suffered recriminations and sometimes lawsuits for not keeping the vulnerabilities secret. When Christopher Soghoian created a website allowing people to print fake airline boarding passes, he got several unpleasant visits from the FBI.

This preference for secrecy comes from confusing a vulnerability with information about that vulnerability. Using secrecy as a security measure is fundamentally fragile. It assumes that the bad guys don't do their own security research. It assumes that no one else will find the same vulnerability. It assumes that information won't leak out even if the research results are suppressed. These assumptions are all incorrect.

The problem isn't the researchers; it's the products themselves. Companies will only design security as good as what their customers know to ask for. Full disclosure helps customers evaluate the security of the products they buy, and educates them in how to ask for better security. The Dutch court got it exactly right when it wrote: "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."

In a world of forced secrecy, vendors make inflated claims about their products, vulnerabilities don't get fixed, and customers are no wiser. Security research is stifled, and security technology doesn't improve. The only beneficiaries are the bad guys.

If you'll forgive the analogy, the ethics of full disclosure parallel the ethics of not paying kidnapping ransoms. We all know why we don't pay kidnappers: It encourages more kidnappings. Yet in every kidnapping case, there's someone -- a spouse, a parent, an employer -- with a good reason why, in this one case, we should make an exception.

The reason we want researchers to publish vulnerabilities is because that's how security improves. But in every case there's someone -- the Massachusetts Bay Transit Authority, the locksmiths, an election machine manufacturer -- who argues that, in this one case, we should make an exception.

We shouldn't. The benefits of responsibly publishing attacks greatly outweigh the potential harm. Disclosure 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 how we learn about security, and how we improve future security.

---

Bruce Schneier is Chief Security Technology Officer of BT Global Services and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World. You can read more of his writings on his website.

So I put together a simple class that holds an XmlDocument and implements ISerializable and called it SerializableXmlDocument. I'm sharing the source code here in the hopes that

a) somebody will find it useful, and

b) somebody smarter than I am will point out how I screwed it up and help me make it better.

SerializableXmlDocument includes implicit conversion operators to make it easy to convert to/from an XmlDocument. It holds the actual document in a property called Value. This "isomorph" pattern is one that I picked up from Craig.

While writing this code, I also wrote a helpful extension method for getting a byte array out of a MemoryStream that is exactly the length of the data written to the stream so far (CopyUpToSeekPointer). So don't go looking in the docs for MemoryStream for this method :) This is obviously not the most efficient way to consume bytes written to a MemoryStream since it copies the data into a new byte array, but it's very convenient in many scenarios.

Here is SerializableXmlDocument.cs:

using System;
using System.Runtime.Serialization;
using System.Xml;
using System.IO;

namespace Pluralsight.Samples
{
    [Serializable]
    public class SerializableXmlDocument : ISerializable
    {
        public SerializableXmlDocument() { }
        public SerializableXmlDocument(XmlDocument value)
        {
            this.Value = value;
        }

        public XmlDocument Value { get; set; }

        #region ISerializable implementation
        public SerializableXmlDocument(SerializationInfo info,
                                       StreamingContext context)
        {
            byte[] serializedData = (byte[])info.GetValue("doc",
                typeof(byte[]));
            if (null != serializedData)
                this.Value = Deserialize(serializedData);
        }

        public void GetObjectData(SerializationInfo info,
                                  StreamingContext context)
        {
            byte[] serializedData = null;
            if (null != Value)
                serializedData = Serialize(Value);
            info.AddValue("doc", serializedData);
        }
        #endregion

        #region implicit conversion to/from XmlDocument
        public static implicit operator SerializableXmlDocument(
            XmlDocument doc)
        {
            return new SerializableXmlDocument(doc);
        }
        public static implicit operator XmlDocument(
            SerializableXmlDocument sdoc)
        {
            return sdoc.Value;
        }
        #endregion

        #region Xml serialization helper methods
        private static byte[] Serialize(XmlDocument doc)
        {
            MemoryStream stream = new MemoryStream();
            doc.Save(stream);
            return stream.CopyUpToSeekPointer();
        }
        private static XmlDocument Deserialize(byte[] serializedData)
        {
            XmlDocument doc = new XmlDocument();
            doc.Load(new MemoryStream(serializedData, false));
            return doc;
        }
        #endregion
    }
}

...and here's the CopyUpToSeekPointer extension method for MemoryStream:

using System;
using System.IO;

namespace Pluralsight.Samples
{
    public static class MemoryStreamExtensionMethods
    {
        public static byte[] CopyUpToSeekPointer(
            this MemoryStream stream)
        {
            // copy only the part of the buffer
            // that contains the serialized document
            long length = stream.Position;
            byte[] buffer = stream.GetBuffer();
            byte[] result = new byte[length];
            for (int i = 0; i < length; ++i)
                result[i] = buffer[i];
            return result;
        }
    }
}

...and here's a sample object that uses SerializableXmlDocument:

using System;

namespace Pluralsight.Samples
{
    [Serializable]
    public class Item
    {
        public string Name { get; set; }
        public SerializableXmlDocument Data { get; set; }

        public void Print()
        {
            Console.WriteLine("Name: {0}", Name);
            Console.WriteLine(Data.Value.OuterXml);
        }
    }
}

...and here's a sample program that creates an instance of Item, serializes it, then deserializes it, printing diagnostics along the way to show that it's working properly.

using System;
using System.Xml;
using System.Runtime.Serialization.Formatters.Binary;
using System.IO;
using Pluralsight.Samples;

class DemoProgram
{
    static void Main(string[] args)
    {
        XmlDocument doc = new XmlDocument();
        doc.LoadXml("<root><child>text</child></root>");

        Item item = new Item
        {
            Name = "Testing 123",
            Data = doc,
        };

        // print object before serialization
        item.Print();

        BinaryFormatter formatter = new BinaryFormatter();
        MemoryStream stream = new MemoryStream();
        formatter.Serialize(stream, item);

        byte[] serializedItem = stream.CopyUpToSeekPointer();

        Console.WriteLine("Serialized data (base64): {0}",
            Convert.ToBase64String(serializedItem));

        item = (Item)formatter.Deserialize(
            new MemoryStream(serializedItem, false));

        // print object after deserialization
        item.Print();
    }
}

Here's the output of the previous sample program:

Flame away!

My favorite talk, as expected, was the Sotirov/Dowd talk on How To Impress Girls With Browser Memory Protection Bypasses. The attack is a conceptually simple, yet completely reliable technique for exploiting vulnerabilities in web browsers. Of course, the media has sensationalized the impact of their findings, but ultimately, this is still significant as far as browser-based exploits are concerned. It’s worth mentioning that part of the technique allowing them to load a .NET DLL at an arbitrary location under Vista was reliant on an implementation bug wherein the OS disables ASLR if the version in the .NET COR header was below a certain value. However, the address space spraying and stack spraying techniques are likely to be extended to other platforms utilizing similar memory protection mechanisms.

As for the girls? I can report first-hand that the ladies at TAO on Wednesday night were hanging on Alex’s every word. They were particularly impressed when he whipped out the laptop for a live demo. Unfortunately, none of the dozen iPhone owners in the immediate vicinity thought to snap a picture (too busy Twittering). Oh well.

I also enjoyed Hovav Shacham’s talk on return-oriented programming. Simply put, he described a generalization of the return-to-libc shellcode approach with the intent to demonstrate that one could achieve Turing-complete computation using “found code” in process images. By chaining together series of mini-computations ending in return (RET) instructions, it was possible to build higher-level programming constructs such as branches and loops. The nature of the x86 instruction set provides some flexibility because instructions are interpreted differently depending on how you align the instruction pointer (i.e. the old shellcode trick of searching the process image for any JMP EBX instruction and using that as your EIP). In RISC architectures such as SPARC, however, you don’t have that luxury; if your %pc isn’t aligned properly you get a bus error. So it was quite interesting to see that they were able to extend the concept to RISC. The practicality of the attack technique is limited by the fact that the shellcode is tuned to a particular binary image — if the shellcode was built using instructions extrapolated from glibc 2.3.5, it won’t work for a system running glibc 2.4.

I thought Scott Stender’s talk on Concurrency Attacks in Web Applications was interesting as well. In a nutshell, spewing thousands of simultaneous requests at web application transactions that are not thread-safe can create interesting problems. In the presentation, Scott ran his demo against a VM running on the attack machine. I found myself wondering how effective the same attack would be over the Internet — would it be significantly less reliable (or not at all)? Race conditions are generally easier to exploit locally than remotely due to more predictable execution conditions. Certainly this is an under-tested vulnerability class though.

One presentation I wasn’t able to attend but want to follow up on is Nate McFeters, John Heasman, and Rob Carter’s talk which discussed the GIFAR attack I’ve been hearing so much about lately. The gist is that you can create a file that is both a valid GIF and a valid JAR, then use some Java applet tricks to initiate HTTP requests on behalf of the victim.

Finally, the Pwnie Awards didn’t fail to disappoint. Drama ensued over the Most Overhyped award, but at least this year some of the winners showed up to claim their awards! Halvar rapping Symantec lyrics was also quite memorable.

All in all, a fun and informative week, but as usual, I was relieved to get the hell out of Vegas and head home on Friday morning.

P.S. For a much more entertaining BlackHat/Defcon Recap, read Jennifer Jabbusch’s account of the week’s events. It’s my favorite one so far!

My favorite talk, as expected, was the Sotirov/Dowd talk on How To Impress Girls With Browser Memory Protection Bypasses. The attack is a conceptually simple, yet completely reliable technique for exploiting vulnerabilities in web browsers. Of course, the media has sensationalized the impact of their findings, but ultimately, this is still significant as far as browser-based exploits are concerned (here is a more accurate report). It’s worth mentioning that part of the technique allowing them to load a .NET DLL at an arbitrary location under Vista was reliant on an implementation bug wherein the OS disables ASLR if the version in the .NET COR header was below a certain value. However, the address space spraying and stack spraying techniques are likely to be extended to other platforms utilizing similar memory protection mechanisms.

As for the girls? I can report first-hand that the ladies at TAO on Wednesday night were hanging on Alex’s every word. They were particularly impressed when he whipped out the laptop for a live demo. Unfortunately, none of the dozen iPhone owners in the immediate vicinity thought to snap a picture (too busy Twittering). Oh well.

I also enjoyed Hovav Shacham’s talk on return-oriented programming. Simply put, he described a generalization of the return-to-libc shellcode approach with the intent to demonstrate that one could achieve Turing-complete computation using “found code” in process images. By chaining together series of mini-computations ending in return (RET) instructions, it was possible to build higher-level programming constructs such as branches and loops. The nature of the x86 instruction set provides some flexibility because instructions are interpreted differently depending on how you align the instruction pointer (i.e. the old shellcode trick of searching the process image for any JMP EBX instruction and using that as your EIP). In RISC architectures such as SPARC, however, you don’t have that luxury; if your %pc isn’t aligned properly you get a bus error. So it was quite interesting to see that they were able to extend the concept to RISC. The practicality of the attack technique is limited by the fact that the shellcode is tuned to a particular binary image — if the shellcode was built using instructions extrapolated from glibc 2.3.5, it won’t work for a system running glibc 2.4.

I thought Scott Stender’s talk on Concurrency Attacks in Web Applications was interesting as well. In a nutshell, spewing thousands of simultaneous requests at web application transactions that are not thread-safe can create interesting problems. In the presentation, Scott ran his demo against a VM running on the attack machine. I found myself wondering how effective the same attack would be over the Internet — would it be significantly less reliable (or not at all)? Race conditions are generally easier to exploit locally than remotely due to more predictable execution conditions. Certainly this is an under-tested vulnerability class though.

One presentation I wasn’t able to attend but want to follow up on is Nate McFeters, John Heasman, and Rob Carter’s talk which discussed the GIFAR attack I’ve been hearing so much about lately. The gist is that you can create a file that is both a valid GIF and a valid JAR, then use some Java applet tricks to initiate HTTP requests on behalf of the victim.

Finally, the Pwnie Awards didn’t fail to disappoint. Drama ensued over the Most Overhyped award, but at least this year some of the winners showed up to claim their awards! Halvar rapping Symantec lyrics was also quite memorable.

All in all, a fun and informative week, but as usual, I was relieved to get the hell out of Vegas and head home on Friday morning.

P.S. For a much more entertaining BlackHat/Defcon Recap, read Jennifer Jabbusch’s account of the week’s events. It’s my favorite one so far!

Doesn’t this seem backwards to you? Shouldn’t the MBTA be suing the vendor who sold them the flawed system? Security problems go away by mandating independant security testing before a product is accepted, not by trying to get security researchers to be quiet. This is a good example of how the reactive approach doesn’t work. The flaws are still in the system and suing researchers has just shined a bright light on them.

Update 08/09/2008 6:00pm EST:

The EFF is appealing the injunction which is blocking the students from speaking about the results of their testing.

A telling quote from Kurt Opsahl, staff attorney at the EFF gets to the heart of the issue:

“Courts have found that the First Amendment covers these things. We believe that this is a protected speech activity. When you discuss security issues, if you are telling the truth, that is something that should be protected.”

Apparently the MBTA has known about this problem since at least March, 2008 when a graduate student from the University of Virginia announced he was able to break the encryption system.

The U of VA researcher gave an interview where he described why security by obscurity is not a valid security approach for a cryptosystem:

Q: What are your thoughts on security by obscurity? Is NXP using this method of protection?

A: Security-through-obscurity hardly ever works. The lack of proper peer-review often even hurts the security of the system. Our Mifare work discovered several vulnerabilities that could be fixed without increasing the cost of the cards. NXP did for a long time rely on obscurity for the security of some of their products, but now decided against this outdated design approach and instead bases the security of newer RFID cards on publicly scrutinized cryptography and independent evaluations.

Q: Can you explain “Kerckhoffs Principle” and why it applies to your work?

A: Kerchoff, who lived in the 19th century, observed that keeping anything secret is really hard. So instead of relying on the secrecy of your whole system, it would a lot easier to only rely on the secrecy of a small secret key. Security systems should hence be publicly known and analyzed, and only the key should be secret. When properly realised for RFID cards, Kerchoff’s principle means that by analyzing their own cards, thieves cannot compromise your cards. This is contrary to our Mifare work, where we only analyzed a few copies of the the secret algorithm that is found in all cards and were consequently able affect the security of all the other billion cards out there.

The MBTA not only accepted a security system which relied on security by obscurity but once accepting this flawed model must try to maintain this obscurity with the court system.

The documents detailing the presentation are here.

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.