Conversations about life & privacy in the digital age

Responsibly Bringing a new Cryptography Product to Market

Post Snowden, technologists have rushed a variety of “liberation tech” projects to market, making boastful claims about their cryptographic capabilities to ensure the privacy of their customers. These goals are noble but the results have sometimes been embarrassing.

We’re building a new crypto product ourselves: a high-level secure-by-default framework developers can use to build end-to-end cryptographic applications without writing crypto.

Here’s what we required:

  1. To be independently verifiable it must be open source
  2. Have a spec
  3. Have a threat model
  4. Have clear, well documented code
  5. Be audited by security professionals with a crypto background

In this post I’ll share how we’re going about #5. We’re committed to development in the open, including security review.

The first audit we could schedule was with 3 researchers from the Least Authority team. Among other reasons we chose them because they have deep experience building verifiable storage systems. For anyone in that market, Tahoe-LAFS is a must read.

Auditing is both expensive and hard to schedule, with leading organizations booked months in advance.  The best teams are not limited by their ability to sell their services but rather by their ability to hire and fulfill that work. Consequently there’s very little downward pressure on their rates.

To get the most from a security audit, it’s best to go in with the cleanest code possible. It’s like brushing your teeth before you visit the dentist. It’s impolite and ineffective to ask someone to puzzle over the subtleties of code you haven’t clarified [1].

We focused this first audit narrowly on a bare bones single-user (no collaboration or multi-user sharing) demo application built with the Crypton framework. Our goal was good coverage of the framework’s core fundamentals: account creation, authentication, and single-user data storage.

Unfortunately, at the time we could schedule the audit to begin, there were three issues that the Crypton team knew about but hadn’t a chance to fix or even document. The auditors independently discovered two of those three issues with a lead to the third issue (less severe) tagged [UNRESOLVED] in their report. Additionally they found three other serious issues unknown to the team. Overall, some of the best money we’ve ever spent!

Since the purpose of this post is to give clear expectations, I think it’s important to share real numbers and cleared this with Least Authority.

Zooko explained, “We gave SpiderOak a small discount on our normal price, and moreover we pushed back our other projects in order to get the work done for you first. We did these two things because we wanted to form a relationship with SpiderOak since you provide end-to-end-encrypted storage, and we wanted to support Crypton because it is end-to-end-encrypted and is fully Free and Open-Source Software.”

Our bill was $30,000, or about $5k/researcher per week.

We have a second audit with the nice folks at Leviathan Security, covering the multi-user features of Crypton, and we’ll share that report when it’s complete. In the meantime, here’s the report (rst, pdf) from the first audit by Least Authority.

Here are some of the resulting GitHub issues and pull requests to
resolve the findings. Issue B, C, D, and E.

The resolution for Issue A involves a switch to SRP based authentication. This was part of the longer term roadmap as it provides several additional benefits, but proved to be a nontrivial undertaking and that effort is still ongoing. Some attention is given to this implementation in the next audit by Leviathan Security.

Update: Zooko at Least Authority just published an article discussing their motivation for accepting the project.

Update 2: The originally published version of this post erroneously linked to a non-final draft of the report from Least Authority. That link is corrected; and the final audit report should say “Version 1, 2013-12-20″ at the top.

NOTES:


[1] Zooko shared a story about an experiment that was conducted by Ping Yee in 2007. The results of the experiment illustrate auditing challenges.

In short several very skilled security auditors examined a small Python program — about 100 lines of code — into which three bugs had been inserted by the authors. There was an “easy,” “medium,” and “hard” backdoor. There were three or four teams of auditors.

1. One auditor found the “easy” and the “medium” ones in about 70 minutes, and then spent the rest of the day failing to find any other bugs.

2. One team of two auditors found the “easy” bug in about five hours, and spent the rest of the day failing to find any other bugs.

3. One auditor found the “easy” bug in about four hours, and then stopped.

4. One auditor either found no bugs or else was on a team with the third auditor — the report is unclear.

See Chapter 7 of Yee’s report for these details.

I should emphasize that that I personally consider these people to be extremely skilled. One possible conclusion that could be drawn from this experience is that a skilled backdoor-writer can defeat skilled auditors. This hypothesis holds that only accidental bugs can be reliably detected by auditors, not deliberately hidden bugs.

Anyway, as far as I understand the bugs you folks left in were accidental bugs that you then deliberately didn’t-fix, rather than bugs that you intentionally made hard-to-spot.

AMA: Interview with Cryptographer, Computer Security Expert Jon Callas

Jon worked on Apple’s Whole Disk Encryption, PGP (Pretty Good Privacy) Universal Server, co-founded the PGP Corporation, is former CTO of Entrust, and current co-founder and CTO at Silent Circle (Global Encrypted Communications). As an inventor and cryptographer, his designs of security products have won major innovation awards from The Wall Street Journal and others.

Last week, you submitted your questions for Jon Callas, one of  the world’s most respected and brilliant minds when it comes to software security and privacy. We chose five of them, which we sent to Jon. These are his answers.

1. How did you become a security expert / cryptographer?

A long time ago, I worked at the best computer science grad school there was — VMS development at Digital Equipment Corporation. One of the great things there was that I got to work on a wide variety of things, from graphics to schedulers to memory management to operating system security. A lot of the problems we had to deal with at the time are still relevant issues. I did a random password generator among other things, and I still use that for my own passwords.

When DEC fell apart, like many people, I started a startup with a number of friends. We built a system that let you do meetings as well as play games, socialize, and collaborate. It got rave reviews. The venture capital people said to us, “This is amazing! I want to invest in this in ten years!” That was when I started getting into cryptography. People didn’t want to do collaboration on the then very-early Internet without encryption. There was no SSL at the time, either.

So I went to the second ever RSA conference to learn to do enough cryptography to protect our network. I ended up sitting next to a guy named Bruce who had just written a book called “Applied Cryptography” and he had a bunch of them in a duffel bag with him, so I bought one. I may have bought the very first copy; I know I was the first person at RSA who bought one. I asked him to autograph it, and he said, “I can’t deface a book!” I replied that it’s not defacement if you’re the author.

After we got tired of throwing our money into our startup, I went to work for Apple in the Advanced Technologies Group and worked for Gurshuran Sidhu, who was the inventor of AppleTalk, and shipped the very first crypto built into an OS, called PowerTalk. It failed for being far too early, as well. One of its pieces, though, was this password manager called The Keychain, and I claimed that it was a great thing. While it was hardly perfect, it encouraged good password use, and that was better than anything else. So Bruce Gaya and I hacked The Keychain so that you could run it without the rest of PowerTalk, and thus rescued it from oblivion. The present Keychain on Apple products is completely and utterly rewritten, but I’m proud of saving it. I also built a random number manager for Macs that’s now lost to the mists of time.

That was the worst time to be working for Apple, the year before Steve Jobs came back. I named all my computers for things in The Hitchhiker’s Guide to the Galaxy, because as I said, having been through DEC’s collapse I felt a bowl of petunias (“Oh, no, not again”). When SJ came back, we heard a lot about what his plans were, as he and Sidhu were old friends. We knew that he was planning to get rid of all of ATG, so we wondered what to do. Sidhu wanted to start a startup, but none of us had any ideas we really liked. I could have easily gone into the OS group. A friend of a friend said that Phil Zimmermann’s PGP Inc was looking for server architects, and I interviewed there and got an offer. I thought it was a great way to do fun things and change the world for the better, so I went there. That was a great place to really become an expert.

2.  Are there any localities where it is illegal to encrypt calls, text messages, or emails?

Maybe. That’s not a good answer, is it?

In civilized countries, the answer is no. I might even go so far as to say that the places where it’s not legal or even expected are pretty tightly correlated with civilized countries. Repressive governments often try to restrict crypto. I’m sure Syria’s got it’s opinions, but I’m not an expert on Syrian law.

There are places where there are restrictions, but they are also so filled with exceptions that it’s hard to give a definitive answer. For example, China has import restrictions on cryptography. But there are exemptions for non-Chinese doing business there or Chinese people who are doing business with other countries. I am also nothing like an expert on Chinese law.

My rule is that I worry about the laws of countries that I want to operate in. I need to know about them, there. Other places I just ignore.

Most often, even in repressive countries, they aren’t worried about the crypto as such, they’re worried about what the people are using the crypto for.

 3. What are you working on right now that has you the most excited?

On a large scale, it’s Silent Circle. The biggest problem we’ve always had with crypto is that it’s hard to use. Usability is key because if it’s hard to use, then people use insecure systems. They don’t stop talking, they stop being secure. So your security has to fade into the background. It has to be ignorable. But it also has to be there, as well. That’s a paradox.

We also have learned one of the best ways to make security workable is to have it run by an expert staff. So the question is how to have an expert staff running the security and privacy for people who need it and yet the staff can’t undetectably compromise the people using the system. We have a lot of innovative things we’re doing to make the security fade into the background and yet be there.

On a small scale, I’m taking my old password generator from VMS and making it into an iPhone app. I was doing a lot of work on it before Silent Circle as a hobby, and I really ought to finish.

4. As an expert on encryption do you see a natural relationship between encryption and the law? What’s your stance on how encrypted data should be treated when there’s no idea what it may contain? In some countries there are what I consider very severe key disclosure laws and I wonder if there will ever be a duress scheme or method of deniable encryption that could be so perfect as to make the laws moot.

I think it’s an unnatural relationship between encryption and the law. All technologies can be used for good or ill. It’s true for fire. It’s true for just about anything. Encryption, interestingly, is rarely *directly* used for ill. Yes, there are data ransom schemes that use encryption for ill, but that’s not what people are concerned about.

It’s part of our belief in human rights that we believe in the right to be left alone. Yet many people lose their nerve when it comes to privacy technologies on computers and networks. I think that’s an artifact of the fact that we’re comfortable with door locks or window curtains, but every time someone thinks about encryption, the James Bond theme starts playing in their head. That’s an artifact of the relationship between encryption and disagreements between nation-states. With the Internet and computing everywhere, not using encryption is like having an unlocked house with no curtains.

“With the Internet and computing everywhere, not using encryption is like having an unlocked house with no curtains.”

My stance on encrypted data per se is that it’s data. Everyone has reasons that they want something to be private. Everyone has things that *must* be private, like their own records or someone else’s records, which usually *must* be protected. This might have been an interesting debate way back in the 1900s, but it isn’t any more.

I don’t know what to say about key or data disclosure laws. In the US, there’s movement in the courts towards protecting encrypted data in some way or other. It’s all revolved around passwords in specific, but the real issue is a Fifth Amendment issue. Relatively few countries have equivalents of the Fifth Amendment.

But the UK, for example, they don’t have protections against self-incrimination. As a matter of fact, we have one in the US *because* they don’t have one there. They have a disclosure law, RIPA. I think its application has been pretty embarrassing, as I can’t think of a place where it has been used that didn’t do much more than make the defendant more sympathetic.

I am not a fan of deniable encryption and personally, I think it’s impossible. Deniable encryption seems to me to be predicated on the idea that your attacker is either a nice person or stupid. Stupid in the sense that you are managing to hide the fact that you’re using deniable encryption. That predicates that either you’re using something completely custom, or they don’t realize that the deniable encryption is there. That’s what I mean by stupid — you’re pulling a fast one on them and they don’t know it. By being nice, they know you have deniable encryption and yet they’ll say, “Well, I guess if we can’t *prove* you have something encrypted there, I guess you don’t!”

A couple of years ago, I was chatting with the customs agency of a civilized country. I asked them about TrueCrypt and its deniable disk volume. They said, “Oh, we know *all* about TrueCrypt!” One of the guys I talked to added, “If we see you’re using TrueCrypt, we just ask you for the second password.” I asked what happens if someone doesn’t have a second volume and they replied, “Why would someone do *that*? I mean, that’s the whole point of TrueCrypt, to have a second volume. What kind idiot would install TrueCrypt and not have a second volume?” We chatted some more and one of them said, “Look, we don’t look in someone’s laptop for no reason. We have better things to do. If we’re asking for your computer, it’s not because they had a piece of fruit in their bag. If we find special encryption, we know we’re on to something.” I asked again about someone who *doesn’t* have a hidden volume, and they said that you’d have to sit in a room for a while, until you convince them you don’t.

This is the real issue, I think. If you’re in a nice jurisdiction — one where you can say, “Look, I’m an honest person and I have encryption, and no I’m not going to tell you my password” then deniable encryption might work. But if you’re in a jurisdiction where they aren’t nice, then you’re actually more at risk using something that makes you look like you’re up to something.

Ironically, this is an effect of the fact that we’ve succeeded in making encryption normal.

 5. What is your favorite movie?

There are relatively few movies that I’m willing to watch more than once. I’m apathetic about special effects, but a sucker for great dialog.

One of the very few movies I can watch over and over is The Princess Bride. One of my favorite lines to live by is, “Nonsense. You’re only saying that because no one ever has.”

Thanks Jon! If you are interested in learning cryptography, we recommend reading his PDF, An Introduction to Cryptography. Otherwise, be sure to follow or like Silent Circle to stay in stride with their efforts and support their work in encrypted communications.

Just Because It’s Encrypted Doesn’t Mean It’s Private

Now that you’ve got a handle on what encryption is and what it can do, it’s important to understand what it can’t do.

Encryption is a tool, and like any tool, it can be used improperly or ineffectively. It may sound a bit strange for us at SpiderOak to disclaim the benefits of encryption, but I hope to show that while encryption is necessary for privacy, it’s not always sufficient.

One prime example of the utility of encryption is HTTPS. By wrapping encryption around regular HTTP, engineers have created a powerful tool for securing content both delivered to you and provided by you. But HTTPS only protects content while it’s in transit. HTTPS will protect your credit card numbers as they travel over the internet to a merchant, but once they arrive on the other end, they’re no longer encrypted and it’s up to the merchant and credit card providers to protect them. Credit card providers and banks have developed PCI DSS regulations to tightly specify the security of credit card processing, but as the frequency of credit card breaches demonstrates, these regulations aren’t sufficient to guarantee privacy.

Another great cryptographic tool is Full Disk Encryption. Whether built-in to your computer hardware or provided by software like TrueCrypt, FDE protects the contents of your hard drive by encrypting every last bit. Anyone who steals your hard drive will find it completely unreadable. But while you’re using the drive, it is readable. While you have your computer on and the drive unlocked, any malicious piece of software running on your computer will find all of your data fully readable. FDE is a valuable tool, but it can only guarantee privacy while the disk isn’t in use.

Privacy is a complex problem that requires attention to many details, one of which is encryption. We’ve tried our best to provide you with the best privacy possible for your important data. If you’re interested in more details about how we protect your privacy, please read our Engineering page. And feel free to ask us about it, we’re always willing to brag!

Ask American computer security expert, Jon Callas

You know that crazy interview question, “If you could have dinner with any famous person, living or dead, who would it be?”

Well, someone the other night answered, Jon Callas. Perhaps there are several of you out there with interest in the world of cryptography and information security and would also enjoy the opportunity to ask him some questions.

While we can’t set up a dinner meeting between you with Jon, we can pass along your questions. Jon has graciously granted us the opportunity to send over our readers’ most burning questions for him to answer.

Take the weekend to submit your questions in the comment section and the folks over here at SpiderOak will pick the best 10 to be submitted to Jon.

Who knows, maybe you’ll get a dinner out of this afterall…