Cyberdeterrence Papers

This just came past my inbox:

The National Research Council (NRC) is undertaking a project entitled “Deterring Cyberattacks: Informing Strategies and Developing Options for U.S. Policy.” The project is aimed at fostering a broad, multidisciplinary examination of strategies for deterring cyberattacks on the United States and the possible utility of these strategies for the U.S. government.

To stimulate work in this area, the NRC is offering one or more monetary prizes for excellent contributed papers that address one or more of the questions of interest found in its call for papers, which can be found at
http://sites.nationalacademies.org/CSTB/CSTB_056215

Abstracts of less than 500 words are due April 1, 2010. First drafts are due May 21, 2010, final drafts July 9, 2010. For more information, see the call for papers.

The broad themes of interest include

  1. Theoretical Models for Cyberdeterrence
  2. Cyberdeterrence and Declaratory Policy
  3. Operational Considerations in Cyberdeterrence
  4. Regimes of Reciprocal/Consensual Limitations Regarding Cyberattack
  5. Cyberdeterrence in a Larger Context
  6. The Dynamics of Action/Reaction in Cyber Conflict
  7. Escalation Dynamics of Cyber Conflict

Readers with questions can contact Herb Lin, 202-334-3191, hlin at nas … edu

Me, I’m glad to see the administration moving towards more contests and open solicitations as a way of tapping into different ideas from a broader set of contributors.

I saw something that an abstract is not required to submit a fill paper, but would encourage checking in on the rules for yourself.

Life without Certificate Authorities

Since it seems like I spent all of last week pronouncing that ZOMG!  SSL and Certificate Authorities is Teh Doomed!, I guess that this week I should consider the alternatives.  Fortunately, the Tor Project Blog, we learn what life is like without CA’s

Browse to a secure website, like https://torproject.org/. You should get the intentionally scary “This Connection is Untrusted” certificate error page. However, you should expect this error as there are no more CAs to valid against. Click “I Understand the Risks”. Click “Add Exception”. Firefox should retrieve the certificate. Click “View”. This is where it gets interesting.

How do you validate the certificate? It depends on the other end. For sites I worry about, like my bank or favorite shopping stores, I call support and ask for the SSL fingerprint and serial number. Sometimes the support person even knows what I’m talking about. I suspect they just open their browser, click on the lock icon and read me the information. Generally, it takes some work to get the information. Further, I’ll compare the cert received through Tor and through non-Tor ssh tunnels on disparate hosts. However, you only have to do this checking once per cert. Once you have it, Firefox stores it as an exception and, if the cert doesn’t change between visits, doesn’t interrupt you with the cert error page.

Even this brings a few caveats:

Does the list of certs in my browser open me up to unique fingerprinting in some way? Would I notice if a Packet Forensics device was used? Unless someone screwed up, I doubt it. And a seldom asked question is, have I ever caught ssl certs being faked or changed by a man-in-the-middle? Yes I have.

And there’s the rub.  Even without using the CA as a proxy for trust, a suitably privileged attacker could still MITM that traffic stream.  So even going it alone is not a panacea, it arguably reduces risk of a successful non-government attacker (i.e. fraudster) by someone who breaches the CA’s verification processes.

Right now, though, I think that for most people, CA’s suffer the same shortfalls which Churchill famous ascribed to Democracy:  “The worst form of online identity verification except for all those others that have been tried.”

Perhaps, as the challenges of PKI alternatives like the Web of Trust, demonstrate, Trust is an inherently un-scalable concept (online).  If that is the case, how do we align and partition risk appropriately and, even more importantly, how do we do it in a manner that the average Internet user will get right, even if they don’t comprehend it?

Updated to correct a typo and clarify another

Going Dutch: Time for a Breach Notification Law

The European Digital Rights Initiative mentions that “Bits of Freedom starts campaign for data breach notification law:”

A data breach notification obligation on telecom providers is already to be implemented on the basis of the ePrivacy Directive, but Bits of Freedom insisted that this obligation should be extended also to other corporations and organisations. It drafted an extensive position paper, including a concrete proposal for amending the Dutch Data Protection Act. Simultaneously, it announced the launch of a “black paper” keeping track of all data breaches in The Netherlands.

If anyone has English translations or summaries, please let me know. I do hope that Bits of Freedom understands the broader context of how good data about breaches can help us overcome so many problems in information security.

Your RIVACY is important to us

…so important that we didn’t even proofread our rivacy policy.

rivacy.jpg

I’m hopeful that they apply more due care to how they administer their policy, but fear it’s like a dirty restaurant bathroom. If they don’t bother to take care of what the public sees, what are they doing in the kitchen?

From “Commercial Terms of Service – Charter Communications.” Thanks to Lanet-Geek for the pointer.

More Bad News for SSL

I haven’t read the paper yet, but Schneier has a post up which points to a paper “Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow,” by Shuo Chen, Rui Wang, XiaoFeng Wang, and Kehuan Zhang.about a new side-channel attack which allows an eavesdropper to infer information about the contents of an SSL connection in certain contexts, some of them fairly common.  For example (from Schneir’s link to Ed Felten’s commentary on the paper):

The new paper shows that this inference-from-size problem gets much, much worse when pages are using the now-standard AJAX programming methods, in which a web “page” is really a computer program that makes frequent requests to the server for information. With more requests to the server, there are many more opportunities for an eavesdropper to make inferences about what you’re doing — to the point that common applications leak a great deal of private information.

Consider a search engine that autocompletes search queries: when you start to type a query, the search engine gives you a list of suggested queries that start with whatever characters you have typed so far. When you type the first letter of your search query, the search engine page will send that character to the server, and the server will send back a list of suggested completions. Unfortunately, the size of that suggested completion list will depend on which character you typed, so an eavesdropper can use the size of the encrypted response to deduce which letter you typed. When you type the second letter of your query, another request will go to the server, and another encrypted reply will come back, which will again have a distinctive size, allowing the eavesdropper (who already knows the first character you typed) to deduce the second character; and so on. In the end the eavesdropper will know exactly which search query you typed. This attack worked against the Google, Yahoo, and Microsoft Bing search engines.

SSL has been touted as a Web security panacea for years, but the harsh reality is that its weaknesses are growing rapidly, made worse by the changing ways that HTTP is used–when the expected SSL-protected transaction was a page request followed by the return of a full page of content, it was extremely difficult to infer the contents of the connection.  Now that the requests and responses are relatively atomic, even down to the characte, this is no longer the case.

And as old assumptions fail, so does security built on top of those assumptions.

Dear SSN-publishing crowd

There’s a bunch of folks out there who are advocating for publishing all SSNs, and so wanted to point out (courtesy of Michael Froomkin’s new article on Government Data Breaches ) that it would be illegal to do so.

42 USC § 405(c)(2)(C)(viii) reads:

(viii)(I) Social security account numbers and related records that are obtained or maintained by authorized persons pursuant to any provision of law enacted on or after October 1, 1990, shall be confidential, and no authorized person shall disclose any such social security account number or related record.

Which doesn’t impact on your policy analysis, but since you need to advocate for a law being changed, we might as well advocate for the right law, rather than a change you hope will have certain effects.

In my view, the right law is one that says that reliance on the SSN for authentication or authorization purposes shall be presumed negligent.

Oh, and Froomkin’s article is delightful too. Take a look.

Smoke, Fire and SSL

Where there’s smoke, there’s fire, goes the adage.

And in the case of an allegedly-theoretical exploit outlined in a new paper by Chris Soghoian and Sid Stamm (the compelled certificate creation attack), the presence of a product whose only use it to exploit it probably indicates that there’s more going on than one would like there, too.  As Wired’s Threat Level notes:

Normally when a user visits a secure website, such as Bank of America, Gmail, PayPal or eBay, the browser examines the website’s certificate to verify its authenticity.

At a recent wiretapping convention, however, security researcher Chris Soghoian discovered that a small company was marketing internet spying boxes to the feds. The boxes were designed to intercept those communications — without breaking the encryption — by using forged security certificates, instead of the real ones that websites use to verify secure connections. To use the appliance, the government would need to acquire a forged certificate from any one of more than 100 trusted Certificate Authorities.

The attack is a classic man-in-the-middle attack, where Alice thinks she is talking directly to Bob, but instead Mallory found a way to get in the middle and pass the messages back and forth without Alice or Bob knowing she was there.

The existence of a marketed product indicates the vulnerability is likely being exploited by more than just information-hungry governments, according to leading encryption expert Matt Blaze, a computer science professor at University of Pennsylvania.

As the paper explains,
While not known to most users, the CAs are one of the weakest links in the SSL public key infrastructure, a problem amplified by the fact that the major web browsers trust hundreds of different firms to issue certificates. Each of these firms can be compelled by their national government to issue a certificate for any particular website that all web browsers will trust without warning. Thus, users around the world are put in a position where their browser entrusts their private data, indirectly, to a large number of governments (both foreign and domestic) whom these individuals would never ordinarily trust.
The assumption that people are taught with SSL is that if the certificate is valid (meaning it is not expired and matches the hostname of the site they’re visiting) and trusted (meaning either they or a Certificate Authority vouch for its authenticity) then the connection is secure from eavesdropping.
The problem is that the decision of whom to trust is being made by people who may or may not share the same security interests as the browser user.  For example, if the United States’ own National Security Agency (NSA) were to compel a CA such as GoDaddy or Verisign or any of 264 CA’s to issue such a certificate within the guise of a National Security Letter, the CA would not only be compelled to comply, but would also be enjoined from ever talking about or acknowledging that they had been required to do so.
The NSA would insist (and might even believe) that they were doing it in the name of “keeping us safe,” but the people they’re targeting would probably feel differently.  Cybercriminals would likewise argue that they’re keeping their income streams safe.  Either way, outsourcing trust has come back to hurt the user.
Thus, the current system of Trustworthy Certificate Authorities has now scaled to the point of failure.  The entities whom we’ve engaged to determine who is or isn’t trustworthy have increasingly shown to have limited ability to deliver in that role.  The only way to be sure that a connection is trustworthy is to keep the trust relationship aligned with the people you actually know and do trust–i.e. run your own private CA and manage your own certificates.  That’s obviously beyond the capabilities of all but a very tiny fraction of the SSL-using world and of limited usefulness other than ensuring relatively secure transport between a closed set of sources.
In the long run, something else is needed.  I don’t know what, but hopefully Soghoian and Stamm’s paper will continue to help drive the discussion.
(Updated to clarify original links)

Well that didn't take long…

The Guardian has reported the first official incident of misuse of full-body scanner information

The police have issued a warning for harassment against an airport worker after he allegedly took a photo of a female colleague as she went through a full-body scanner at Heathrow airport.

The incident, which occurred at terminal 5 on 10 March, is believed to be the first time an airport worker has been formally disciplined for misusing the scanners.

Here was the chance to set the standard for abuse and all he got was a warning.  Adjust privacy expectations accordingly.  And it doesn’t sound like the co-worker is taking it as well as Shah Rukh did.

The New School on Lady Ada Day

Today is Ada Lovelace Day, an international day of blogging to celebrate the achievements of women in technology and science.

For Lady Ada Day, Andrew and I want to thank Jessica Goldstein, our editor at Addison Wesley. Without her encouragement, feedback and championing, we never would have published the New School.

The first proposal we did was for a book to be called “Security Decisions.” Jessica rejected it, and gave us clear reasons why. We pretended to pay attention and re-submitted the same proposal with a new title and a coat of paint. She bought it, and somewhere along the way, we realized she was right. We then wrote the book that inspired this blog.

Thank you, Jessica.