A Taxonomy of PRISM Possibilities

I have been fielding a decent number of calls and emails from reporters on the NSA PRISM scandal. A lot of people are trying to synthesize reasonable technical explanations for how the NSA could implement the program described in the leaked PowerPoint deck and keep it secret for so long. In an effort to improve the quality of the public discussion, I have decided to create a taxonomy of the theories that I have seen floated and supply my own commentary in italics.

To be clear, I have no special knowledge or insight into this program. Everything listed below is based upon data contained in the news articles I have seen. I also recognize that many of these theories sound far-fetched, although I have to admit that my personal Overton Window for crazy conspiracy theories has shifted in the last 24 hours.

My goal is to keep this list up to date as more information is published, so please let me know if you have any corrections or additions by leaving a comment or via email. My GPG key is available here.

The list is below the fold…

Continue reading

The Truth about Aaron Swartz’s “Crime”

I did not know Aaron Swartz, unless you count having copies of a person’s entire digital life on your forensics server as knowing him. I did once meet his father, an intelligent and dedicated man who was clearly pouring his life into defending his son. My deepest condolences go out to him and the rest of Aaron’s family during what must be the hardest time of their lives.

If the good that men do is oft interred with their bones, so be it, but in the meantime I feel a responsibility to correct some of the erroneous information being posted as comments to otherwise informative discussions at Reddit, Hacker News and Boing Boing. Apparently some people feel the need to self-aggrandize by opining on the guilt of the recently departed, and I wanted to take this chance to speak on behalf of a man who can no longer defend himself. I had hoped to ask Aaron to discuss these issues on the Defcon stage once he was acquitted, but now that he has passed it is important that his memory not be besmirched by the ignorant and uninformed. I have confirmed with Aaron’s attorneys that I am free to discuss these issues now that the criminal case is moot.

I was the expert witness on Aaron’s side of US vs Swartz, engaged by his attorneys last year to help prepare a defense for his April trial. Until Keker Van Nest called iSEC Partners I had very little knowledge of Aaron’s plight, and although we have spoken at or attended many of the same events we had never once met.

Continue reading

Answering Questions about .Secure

The initial tech press coverage of Artemis and .Secure has been very gratifying, although it creates a situation where many people are raising the same questions or concerns. Instead of trying to respond to everybody in 160 characters I have created a living FAQ page to accumulate questions and answers.  Let me know if there is a question you would like me to add.

Posted from Peet’s Coffee, San Carlos, California

Introducing something that might become the Domain Policy Framework

I have already started to lay out why we are going after the .secure TLD, let’s start the discussion of how it would be different.

As I have repeated to a dozen reporters in the last 36 hours, there are three legs to the .secure tripod, Verify, Secure and Enforce.  Although we are able to mandate the security controls and protocols be put in place by servers under .secure with today’s technology, we do not have the ability to communicate this escalated level of protection to the browser.  Doing so is a critical component of providing the effortless end-to-end secure experience that I believe users deserve.

To that end we are working on chartering the Domain Policy Working Group.  We cannot announce the initial slate of members while legal work is still occurring, but I do appreciate the support that others have voiced for the project.

I have attached our very very very early draft below.  This document was meant to explore the opportunities provided to us by a protocol like DPF, and there is a lot of work to be done before it is ready for the IETF.  In the meantime, feel free to leave comments here to send them to alex at artemis.net.  If you are really inspired to help, then let us know at info at domainpolicy.org and we’ll let you know when membership slots open.

Please keep in mind that this protocol is meant to be usable on any TLD, and in fact part of Artemis’ business will be to host DPF and other security services on behalf of security-sensitive TLDs.  This protocol should also be usable by the incumbent TLDs, so it’s important to design something that can scale to .com size while not negatively affecting sites that do not opt-in to DPF services.

Posted from the now freezing sidewalk outside Cafe Nero, Waterloo Bridge, London

Why .Secure? Part I: Listening to the User

“Security and usability must not be in conflict. If it’s not safe, it’s not usable; if it’s not usable, it can’t be used safely.”
            – Chris Palmer, circa 2008

If you are one of the dozens of people who have found this blog you undoubtedly have heard of our controversial conversation-starting proposal to operate the .secure TLD.  I thought I would take this opportunity to discuss our motivations for going after this part of the namespace before diving into more technical details.

The Internet experience is completely broken for the vast majority of the world.  Of all of the problems that could lead one to this conclusion (I18N, governance, the inability to leave behind 1970’s technology) I would like to focus on an area somewhat within my expertise: trust and safety.  As you read this, on this planet someone is using a laptop on a café wifi network to pay a bill, over there that person is clicking on a link from an SMS message, and a lot of people are sending private information in an email.

If you interrupted any of these people and asked verbally if they trusted the Internet, or more specifically the technology they held in their hand that moment, they would likely hear the leading tone in your voice and answer “No.”  Yet apparently they each believe that the likelihood of a negative outcome is so low that there is no need to think before performing these actions.  Why do they think that?  In the developed world I would guess this “trust” derives from the trust we have been trained to put into all technology.  Do you carefully read a status message and push the correct button to keep your car from exploding?  Do you have to perform a risk assessment each time you cross a bridge?  No, you do not, because the engineers behind these types of products understand risk management under real world use and a great deal of thought is put into fool-proofing them against even a first decile consumer.

Should we blame them that they expect the same from us, the software and security engineers who build the shiny things they love?  When a normal, intelligent educated person picks up a $400 device with the computing power of Apollo-era NASA they naturally assume that somebody has taken care of problems like “click on the wrong link and my phone turns into a spam sending zombie”.  Sure, they read about malware, and hackers, and account take-over… “Heck, Aunt Julie had her identity stolen last year, and nobody figured out how.” I think it’s clear that even the most aware consumer still assumes that there is a man behind the curtain.

Which brings us to our topic, misplaced trust in the web.  This is a dialog that perhaps hundreds of thousands of people see each day:

 

Safari Certificate Error

 

Imagine that your uncle calls you, asking which button it is safe to push.  Where do you start the conversation?  An introduction to discrete mathematics?  A treatise on the difficulty of factoring large numbers across a finite field? An introduction to the X.509v3 standard?

I have deep sympathy for the browser engineers who maintain this code; they have been given the impossible job of creating a user experience that warns a user without bothering them and that allows a user to accept a risk they almost certainly do not understand.  We have come a long way from the completely obtuse dialogs of the past, but I doubt the average user is more likely to make the correct choice than they did with IE4.

One of the key goals of .secure is to invert the user’s security experience.  The human does not exist to serve the software.  Why does the user politely ask “I would like to go to my bank” and then need to interpret the 21st century pixelated entrails to determine if they arrived at their destination safely?  The user is in charge; they tell the software what they want, and it’s our jobs to make the software listen.

 

 

In my view, .secure is not a category, it is an expression of intent.  When a user types bank.secure, they are not saying “I want to go to the bank in the category of secure”, they are saying “I want to go to my bank securely”.  That means that all of the software standing between them and their destination needs to understand this intent, and then make the thousands of small decisions needed to make it so.   .Secure and the Domain Policy Framework are not the only ways to make that happen, but I believe they are the most expedient.

Posted from the sidewalk in front of Cafe Nero (cafes close at 8!?!), Waterloo Bridge, London
Follow

Get every new post delivered to your Inbox.

Join 104 other followers