Around the same time, researchers discovered that Dropbox stores user files “unencrypted.” Dozens (hundreds?) closed their accounts in protest. They’re my confidential files, they cried, why couldn’t you at least encrypt them?

Many, including some quite tech-savvy folks, were quick to indicate that it would have been so easy to encrypt the data. Not encrypting the data proved Sony and Dropbox’s incompetence, they said.

In my opinion, it’s not quite that simple.

Encryption is easy, it’s true. You can download code that implements military-grade encryption in any programming language in a matter of seconds. So why can’t companies just encrypt the data they host and protect us from hackers?

The core problem is that, to be consumable by human users, data has to be decrypted. So the decryption key has to live somewhere between the data-store and the user’s eyeballs. For security purposes, you’d like the decryption key to be very far from the data-store and very close to the user’s eyeballs. Heck you’d like the decryption key to be *inside* the user’s brain. That’s not (yet) possible. And, in fact, in most cases, it isn’t even practical to have the key all that far from the data-store.

encryption relocates the problem

Sony needs to be able to charge your credit card, which requires your billing address. They probably need to do that whether or not you’re online, since you’re not likely to appreciate being involved in your monthly renewal, each and every month. So, even if they encrypt your credit card number and address, they also need to store the decryption key somewhere on their servers. And since they probably want to serve you an “update your account” page with address pre-filled, that decryption key has to be available to decrypt the data as soon as you click “update my account.” So, if Sony’s web servers need to be able to decrypt your data, and hackers break into Sony’s servers, there’s only so much protection encryption provides.

Meanwhile, Dropbox wants to give you access to your files everywhere. Maybe they could keep your files encrypted on their servers, with encryption keys stored only on your desktop machine? Yes… until you want to access your files over the Web using a friend’s computer. And what if you want to share a file with a friend while they’re not online? Somehow you have to send them the decryption key. Dropbox must now ask its users to manage the sharing of these decryption keys (good luck explaining that to them), or must hold on to the decryption key and manage who gets the key…. which means storing the decryption keys on their servers. If you walk down the usability path far enough – in fact not all that far – it becomes clear that Dropbox probably needs to store the decryption key not too far from the encrypted files themselves. Encryption can’t protect you once you actually mean to decrypt the data.

The features users need often dictate where the decryption key is stored. The more useful the product, the closer the decryption key has to be to the encrypted data. Don’t think of encryption as a magic shield that miraculously distinguishes between good and bad guys. Instead, think of encryption as a mechanism for shrinking the size of the secret (one small encryption key can secure gigabytes of data), thus allowing the easy relocation of the secret to another location. That’s still quite useful, but it’s not nearly as magical as many imply it to be.

what about Firefox Sync, Apple TimeMachine, SpiderOak, Helios, etc.

But but but, you might be thinking, there are systems that store encrypted data and don’t store the decryption key. Firefox Sync. Apple’s TimeMachine backup system. The SpiderOak online backup system. Heck, even my own Helios Voting System encrypts user votes in the browser with no decryption keys stored anywhere except the trustees’ own machines.

It’s true, in some very specific cases, you can build systems where the decryption key is stored only on a user’s desktop machine. Sometimes, you can even build a system where the key is stored nowhere durably; instead it is derived on the fly from the user’s password, used to encrypt/decrypt, then forgotten.

But all of these systems have significant usability downsides (yes, even my voting system). If you only have one machine connected to Firefox Sync, and you lose it, you cannot get your bookmarks and web history back. If you forget your Time Machine or SpiderOak password, and your main hard drive crashes, you cannot recover your data from backup. If you lose your Helios Voting decryption key, you cannot tally your election.

And when I say “you cannot get your data back,” I mean you would need a mathematical breakthrough of significant proportions to get your data back. It’s not happening. Your data is lost. Keep in mind: that’s the whole point of not storing the decryption key. It’s not a bug, it’s a feature.

and then there’s sharing

I alluded to this issue in the Dropbox description above: what happens when users want to share data with others? If the servers don’t have the decryption key, that means users have to pass the decryption key to one another. Maybe you’re thinking you can use public-key encryption, where each user has a keypair, publishes the public encryption key, and keeps secret the private decryption key? Now we’re back to “you can’t get your data back” if the user loses their private key.

And what about features like Facebook’s newsfeed, where servers process, massage, aggregate, and filter data for users before they even see it? If the server can’t decrypt the data, then how can it help you process the data before you see it?

To be clear: if your web site has social features, it’s very unlikely you can successfully push the decryption keys down to the user. You’re going to need to read the data on your servers. And if your servers need to read the data, then a hacker who breaks into the servers can read the data, too.

so the cryptographer is telling me that encryption is useless?

No, far from it. I’m only saying that encryption with end-user-controlled keys has far fewer applications than most people think. Those applications need to be well-scoped, and they have to accompanied by big bad disclaimers about what happens when you lose your key.

That said, encryption as a means of partitioning power and access on the server-side remains a very powerful tool. If you have to store credit card numbers, it’s best if you build a subsystem whose entire role is to store credit-card numbers encrypted, and process transactions from other parts of your system. If your entire system is compromised, then you’re no better off than if you hadn’t taken those precautions. But, if only part of your system is compromised, encryption may well stop an attacker from gaining access to the most sensitive parts of the system.

You can take this encryption-as-access-control idea very far. An MIT team just published CryptDB, a modified relational database that uses interesting encryption techniques to strongly enforce access control. Note that, if you have the password to log into the database, this encryption isn’t going to hide the data from you: the decryption key is on the server. Still, it’s a very good defense-in-depth approach.

what about this fully homomorphic encryption thing?

OK, so I lied a little bit when I talked about pre-processing data. There is a kind of encryption, called homomorphic encryption, that lets you perform operations on data while it remains encrypted. The last few years have seen epic progress in this field, and it’s quite exciting…. for a cryptographer. These techniques remain extremely impractical for most use cases today, with an overhead factor in the trillions, both for storage and computation time. And, even when they do become more practical, the central decryption key problem remains: forcing users to manage decryption keys is, for the most part, a usability nightmare.

That said, I must admit: homomorphic encryption is actually almost like magic.

the special case of passwords

Passwords are special because, once stored, you never need to read them back out, you only need to check if a password typed by a user matches the one stored on the server. That’s very different than a credit-card number, which does need to be read after it’s stored so the card can be charged every month. So for passwords, we have special techniques. It’s not encryption, because encryption is reversible, and the whole point is that we’d like the system to strongly disallow extraction of user passwords from the data-store. The special tool is a one-way function, such as bcrypt. Take the password, process it using the one-way function, and store only the output. The one-way function is built to be difficult to reverse: you have to try a password to see if it matches. That’s pretty cool stuff, but really it only applies to passwords.

So, if you’re storing passwords, you should absolutely be passing them through a one-way function. You could say you’re “hashing” them, that’s close enough. In fact you probably want to say you’re salting and hashing them. But whatever you do, you’re not “encrypting” your passwords. That’s just silly.

encryption is not a magic bullet

For the most part, encryption isn’t magic. Encryption lets you manage secrets more securely, but if users are involved in the key management, that almost certainly comes at the expense of usability and features. Web services should strongly consider encryption where possible to more strictly manage their internal access controls. But think carefully before embarking on a design that forces users to manage their keys. In many cases, users simply don’t understand that losing the key means losing the data. As my colleague Umesh Shankar says, if you design a car lock so secure that locking yourself out means crushing the car and buying a new one, you’re probably doing it wrong.

1. the server could get overwhelmed by attackers, preventing voting altogether
2. the server could get hacked and the votes changed surreptitiously
3. the users’ machines could get compromised by a virus, which would then flip votes as it chooses with little or no trace
4. even if somehow we secure the entire digital channel, there’s still the issue of your spouse looking over your shoulder, strongly suggesting you vote a certain way

So, terrifying. And yet, I’m now pretty sure it is inevitable.

What human activity isn’t on the Internet?

Today, we bank online, deposit checks and even pay vendors with our smart phones. We can change our mailing address with the postal service and pay parking tickets with our local governments online. We can shop online, socialize online, and debate with our Presidential candidates online. Newt Gingrich announced his Presidential campaign on Twitter.

Just about everyone now carries an Internet-connected personal device. The Internet is everywhere you want it, and just about everywhere you don’t. People are starting to experience the world through augmented reality, using online maps and satellite overlays matched with your current location. The Internet is only going to become more omnipresent, faster. Within a few years, it’s hard to imagine any human activity that doesn’t involve the Internet.

And yet, somehow, we expect people to still be voting in person, on paper? We can’t even get users to take SSL certificate warnings seriously, but we’re going to convince them that voting is so special it has to be done in person? I don’t think so.

Don’t grab your pitchfork yet

I’m not arguing that this is how it should be. I’m definitely not saying that we can secure online voting just like we can secure online banking. In fact I’ve made many of the original arguments, in my dissertation and on this blog, shooting down the bogus arguments that go something like “hey, we can secure online banking, surely we can secure online voting!” No, we don’t know how to do that.

What I’m saying is that, regardless of the state of online voting security, I think it’s a losing battle to expect voting to remain the only activity we still do in person and on paper. With the Oscars moving to online voting, the Federal Voting Assistance Program making $15M available in grants for activities related to online voting (even if it supposedly doesn’t involve online vote casting), parts of Canada moving to online voting, France considering online voting for its 2M+ expats (more than the margin of victory in the last Presidential election), what you’re hearing is the sound of inevitability.

Enforced Privacy is Dead

There’s another interesting issue, when you think about problem (4): even if we keep voting on paper in person, voting requires enforced privacy: we have to make sure it’s just you in the voting booth, not you plus a coercer. That’s great. Now, how many ballots do you think we’re going to see next year published on Instagram?

We have a deeper problem here due to the now omnipresent Internet. Voluntary privacy is not dead, since users can choose to isolate themselves. But enforced privacy, privacy imposed on the voter, the kind needed to prevent coercion, that’s quite dead. I’m very concerned about what that means for democracy. But again, this is inevitable.

Doing the Best We Can

So, if it’s inevitable, maybe the best we can do is make online voting as secure as possible. We’ll probably have a few disasters, maybe even a few thrown elections. So we’d better start now on the problems we have.

I think we can solve Problem (2) with open-audit, end-to-end voting systems like Helios (but not only Helios, there are others.) I think we can minimize the risk of Problem (1) by moving to a longer voting period (1 week instead of 1 day). I suspect we have to eventually give up on some aspects of (4), whether or not we do online voting, though some technical tricks might make voter coercion a good bit more difficult (it’s never completely impossible). The hardest problem is (3): we have no way of ensuring that people are using trustworthy software that captures their intent properly.

Again, I’m not endorsing online voting for public office. I’m saying it’s inevitable, and it’s time to face that inevitability.

Importance of the User Agent and why I joined Mozilla

This issue of trustworthy user software is a much larger problem than voting. As human activity increasingly moves online, the central question is: what software is truly on the side of the user? How does the user know for sure that the software they’re using is their true agent? There’s only one piece of Internet architecture today that can be the user’s true agent, and that’s the Web browser (which technologists call the User Agent, unsurprisingly.) And, among the web browsers, there’s one that particularly stands out as the ultimate user agent, backed by a company whose mission is focused on the user and only the user.

That’s why I joined Mozilla. Because for voting and beyond, everything people do is online or soon to be online, and users better have an agent on their side. The best agent users can get today is Firefox, and I hope to contribute to making it an even better user agent in the next few years.

[It's worth noting that Mozilla has no intention of getting into the voting business, that's just my personal interest.]

OK, you may now get out your pitchfork.

Yesterday, the Sony Playstation Network of 75 million gamers was compromised. Names, addresses, and possibly credit cards were accessed by attackers. This may well be the largest data breach in history.

And a few days ago, it was discovered that iPhones keep track of your location over extended periods of time and copy that data to backups, even if you explicitly tell your iPhone not to track your location. There are believable claims that law enforcement has already used this information without a court order. Apple now says this was a bug and they’re fixing it.

In 1984, Stewart Brand famously said that information wants to be free. John Perry Barlow reiterated it in the early 90s, and added “Information Replicates into the Cracks of Possibility.” When this idea was applied to online music sharing, it was cool in a “fight the man!” kind of way. Unfortunately, information replication doesn’t discriminate: your personal data, credit cards and medical problems alike, also want to be free. Keeping it secret is really, really hard.

I get the sense that many think Epsilon and Sony were stupidly incompetent, and Apple was evil. This fails to capture the nature of digital data. It’s just incredibly hard to secure data when one failure outweighs thousands of successes. In the normal course of development, data gets copied all over the place. It takes a concerted effort to enumerate the places where data end up, to design defensively against data leakage, and to audit the code after the fact to ensure no mistakes were made. One mistake negates all successes.

Here’s one way to get an intuitive feel for it: when building a skyscraper, workers are constantly fighting gravity. One moment of inattention, and a steel beam can fall from the 50th floor, turning a small oversight into a tragedy. The same goes for software systems and data breaches. The natural state of data is to be copied, logged, transmitted, stored, and stored again. It takes constant fighting and vigilance to prevent that breach. It takes privacy and security engineering.

The kicker is that, while it’s unlikely to get into the business of building skyscrapers by accident, it’s incredibly easy to find yourself storing user data long before you’ve laid out decent privacy and security practices: Sony built game consoles, and then one day they were suddenly storing user data. It’s also far too common for great software engineers to deceive themselves into thinking that securing user data is not so hard, because hey, they would never be as stupid as those Sony engineers.

So, am I excusing Epsilon, Sony, and Apple? Not at all. But if we keep thinking that they were just stupid/evil, then we are far from understanding and fixing the problem.

I’ve just finished reading Atul Gawande’s The Checklist Manifesto, which I strongly recommend. As industries mature (flying airplanes, practicing medicine, building complex software systems,…), they must build in processes to counteract inevitable human weaknesses. There’s bound to be resistance from experienced practitioners who see the introduction of process as insulting to their craft. Programmers are, in this sense, a lot like doctors. But it’s time to stop being heroes and start being professionals. Storing user data safely is easy until it’s not.

We are constantly fighting nature to meet our stated goals: we don’t want buildings to fall, disease to kill us, or private information to leak. For a little while, it’s okay to fail catastrophically and act surprised. But eventually, these failures are no longer surprising, they’re just negligent. That time of transition for software architects is now. Every company that dabbles in user data should assign a dedicated security and privacy team whose sole responsibility is to protect user data. We will not eliminate all failures, but we can do much, much better.

warning signs

Last year, Chris Soghoian and Sid Stamm published a paper, Certified Lies [PDF], which identified the very issue that is at the center of this week’s crisis. Matt Blaze provided, as usual, a fantastic explanation:

A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don’t even do that much.

A Certificate Authority is a company that your web browser trusts to tell it who is who on the Internet. When you go to https://facebook.com, a Certificate Authority is vouching that, yes, this is indeed Facebook you’re talking to directly over a secure channel.

What Chris and Sid highlighted is an interesting detail of how web browsers have chosen to handle trust: any Certificate Authority can certify any web site. That design decision was reasonable in 1994, when there were only two Certificate Authorities and the world was in a rush to secure web transactions. But it’s not so great now, where a Certificate Authority in Italy can delegate its authority to a small reseller, who can then, in turn, certify any web site, including Facebook and Gmail, using more or less the level of assurance the small reseller sees fit.

what happened

It looks like someone from Iran hacked into one of the small resellers three degrees of delegation away from Comodo to issue to some unknown entity (the Iranian government?) certificates for major web sites, including Google and Microsoft. This gave that entity the power to impersonate those web sites, even over secure connections indicated by your browser padlock icon. It’s important to understand that this is not Google or Microsoft’s fault. They couldn’t do anything about it, nor could they detect this kind of attack. When Comodo discovered the situation, they revoked those certificates… but that didn’t do much good because the revocation protocol does not fail safely: if your web browser can’t contact the revocation server, it assumes the certificate is valid.

a detour via Dawkins, Evolution, and the Giraffe

Richard Dawkins, the world-famous evolutionary biologist, illustrates the truly contrived effects of evolution on a giraffe. The laryngeal nerve, which runs from the brain to the larynx, takes a detour around the heart. In the giraffe, it’s a ludicrous detour: down the animal’s enormous neck, around the heart, and back up the neck again to the larynx, right near where the nerve started to begin with!

If you haven’t seen this before, you really need to spend the 4 minutes to watch it:

In Dawkins’s words:

Over millions of generations, this nerve gradually lengthened, each small step simpler than a major rewiring to a more direct route.

and we’re back

This evolution is, in my opinion, exactly what happened with certificate authorities. At first, with only two certificate authorities, it made sense to keep certificate issuance as simple as possible. With each added certificate authority, it still made no sense to revamp the whole certification process; it made more sense each time to just add a certificate authority to the list. And now we have a giraffe-scale oddity: hundreds of certificate authorities and all of their delegates can certify anyone, and it makes for a very weak system.

This isn’t, in my mind, a failure of software design. It’s just the natural course of evolution, be it biology or software systems. We can and should try to predict how certain designs will evolve, so that we can steer clear of obvious problems. But it’s very unlikely we can predict even a reasonable fraction of these odd evolutions.

the opportunity

So now that we’ve had a crisis, we have an opportunity to do something that Nature simply cannot do: we can explore radically redesigned mechanisms. We can intelligently design trust. But let’s not be surprised, in 15 years, when the wonderful design we outline today has evolved once again into something barely viable.

taking further example from nature?

Nature deals with this problem of evolutionary dead-ends in an interesting way: there isn’t just one type of animal. There are thousands. All different, all evolving under slightly different selection pressures, all interacting with one another. Some go extinct, others take over.

Should we apply this approach to software system design? I think so. Having a rich ecosystem of different components is better. We shouldn’t all use the same web browser. We shouldn’t all use the same trust model. We should allow for niches of feature evolution in this grand ecosystem we call the Web, because we simply don’t know how the ecosystem will evolve. How do we design software systems and standards that way? Now that’s an interesting question…

The only nitpick I have, and I point it out because I think it’s significant in Facebook’s case, is that the announcement confuses privacy and security. The first paragraph mentions Data Privacy Day, then the general concept of controlling your data, then transitions to the new security features. But those are quite different.

Security is about stopping the bad guys from stealing your data. Privacy is about controlling the good guys’ handling of your data. (Ron Rivest is said to have phrased this most eloquently, but I can’t find his quotation.)

So, SSL and social re-authentication provide security because they prevent bad guys from seeing your network traffic at the coffee shop or stealing your login. That’s fantastic, but it has little to do with privacy. If Facebook wanted to celebrate Data Privacy Day specifically, they might consider giving users more control over their data on Facebook. Maybe letting users control who gets to tag them in photos (i.e. not my stalker). Or letting users indicate fields by which advertisers cannot target them (i.e. sexual orientation.) Those would be privacy features.

I don’t mean to knock Facebook’s announcement: it’s great. But it’s about security, not privacy.

That said, I’m not a Java Community expert, so I won’t comment much more on this conflict, other than to say, wait a minute, what’s this from Tim Peierls’s resignation note?

Several of the other EC members expressed their own disappointment while voting Yes. I’m reasonably certain that the bulk of the Yes votes were due to contractual obligations rather than strongly-held principles.

Wait a minute, the Executive Committee votes by public ballot? They’re influenced by contractual obligations? That’s fascinating, and that’s hardly democratic! It means that, even where standards bodies are concerned, the secret ballot might be a very interesting tool.

There are arguments against the secret ballot in this case, of course: maybe the Executive Committee members are representative of the Java Community, and as such they should serve their constituents? Much like legislators, their votes should be public so the community can decide whether or not to reelect them? In that case, contractual obligations to vote a certain way should be strictly disallowed or required to be published along with the vote… To whom are these Executive Committee members accountable? To themselves as well-intentioned guides of the Java community? To the people who elected them? It’s difficult to have it both ways, since one requires a secret ballot, and the other a public ballot.

Maybe the right solution is to publish all comments, but keep the ballots secret? There’s always a chance that a truly hypocritical member would consistently vote differently than their publicly stated opinions, but I’m not sure that risk is worse than the problems the Java Community just faced with what appears to be anything but a democratic vote. In a tough spot like this one, it seems to me that Executive Committee members should be able to vote their conscience without fear of retribution.

(Oh, and if the Java community is looking for a secure voting system, I might have a suggestion.)

As I stated yesterday, I don’t think that’s going to happen anytime soon. I would love to be wrong, because certainly if we could switch to SSL for everything, the Web would be significantly more secure. I just don’t think it’s going to be that easy. But let’s explore this a bit, because I think most people agree that there would be tremendous benefits.

A number of folks are saying “SSL is too expensive.” Others are saying “Google did it, they say it’s 1% overhead, you’re lying.” The main reference people are using for that latter claim is a fascinating presentation by Adam Langley of Google entitled Overclocking SSL. The gist of it is that, using only software, Google gets the overhead of SSL to be 1% CPU and 2% network. That sounds pretty cheap. That said, I’m skeptical. I’m far from the SSL configuration expert, of course, but I don’t think Adam Langley’s presentation paints a complete picture of the situation:

1. per-request overhead, or per-user-visit overhead? When Google says “1% of CPU and 2% of network,” do they take into account the significantly increased number of requests due to reduced browser caching? Specifically, when going over SSL, browsers tend not to cache things like JavaScript files, images, etc… So when you click from page to page, your browser re-downloads a whole bunch of additional files on each click that they would not download if the same site were visited over HTTP. The server has no control over this. So, I suspect Google is looking at each request they get, and saying the SSL portion accounts for 1% CPU and 2% network. But, they’re probably not telling us how many extra requests overall they’re getting by user visit. I suspect it’s quite a bit higher, on the order of 300-400% the number of total requests per user visit, simply because those additional files don’t get cached. And what’s worse, those un-cached requests are typically large files, like graphics.
2. fancy protocol tweaks. Google is doing all sorts of fancy things to reduce the complexity of the SSL negotiation. That’s awesome. But it looks like I need to upgrade to an experimental version of Apache to get all those tweaks. Also, some of the recommendations in Adam’s presentation, e.g. “don’t make SSL_write calls with small amounts of data”, are very difficult for typical web developers to address, since they usually don’t control their web pipeline that well. Finally, it looks like Google has patched OpenSSL to be more efficient. Awesome. Can we see that patch? I’m sure Google has done a fantastic job on all of these protocol, algorithmic, and implementation optimizations. But these are not within the reach of most developers, even good developers.

Now, I’m not an SSL-naysayer! I would love to see SSL deployed everywhere. I just think we need to look at the hard data regarding the overhead this will create for companies and for consumers (no caching = increased bandwidth requirements). There’s one way forward I’d love to see happen: Hey Google, how about open-sourcing all of those tweaks in one super awesome SSL proxy that we can all install blindly in front of our HTTP-only sites? This proxy should implement the latest protocol tweaks, buffer the content in appropriately sized chunks, optimize the algorithm negotiation depending on the underlying hardware, etc. Then we can all experiment with this software, see how it affects performance, and make truly informed decisions about switching to SSL everywhere.

As a side note, I wonder whether one reason Google switched its main search UI to AJAX is that it gets around the issue of re-downloading static files over SSL, since JavaScript and graphics stay in place while only the raw results are updated… That is certainly one useful way to keep things snappy over SSL!

(I must also point out Ben Laurie’s post on this topic and his always-hilarious take, “these are not the credentials you’re looking for!”)

Some folks are wondering if this will be a watershed event where major sites will suddenly shift to serving everything over SSL. I don’t think so. The performance implications of serving everything, including static content, over SSL, are staggering. While working on my secure voting system Helios, I noticed that I could easily serve a static image over HTTP about 1500 times per second on a medium-sized server. Add SSL to that, and squeezing out more than 50 images per second becomes a significant challenge. Now, I’m sure there are folks who can tweak SSL far better than I, but it’s still going to be a significant amount of overhead, not to mention that caching content over SSL typically doesn’t happen, which means every graphic, every JavaScript file, is reloaded every time the user navigates to a new page. At the end of the day, a web site served over SSL is a significant amount of extra server-side overhead and, even if you do it right, it just won’t be as snappy in the browser. Users will complain, and that makes SSL-everywhere very unlikely. I would be happy to be proven wrong, but I just don’t think SSL everywhere is happening anytime soon.

What sucks is that there is no in-between. It would be nice if a web page could mix and match SSL and non-SSL components, so that images and JavaScript could be loaded without the overhead of SSL. Of course, that’s not nearly as secure, but it would defend against a passive attacker like FireSheep. Active attackers would still be able to cause damage, but then again active attackers are quite a bit harder to achieve and to defend against, so maybe an in-between defense is good enough. Unfortunately, if you try to mix and match secure and insecure resources, you get some nasty warnings / broken locks on most browsers. For good reason, too, since the browsers are defending against active attackers, but still, too bad there’s no usable way to achieve in-between security.

It would also be nice if web developers could easily use a more secure approach to authentication, one that doesn’t simply send over a cookie. Something like HTTP Digest Auth, only of course *not* Digest Auth itself since that doesn’t fit in nicely with the way web sites like to manage their users’ sessions (timeouts, explicit logout, …)

SessionLock Lite

A couple of years ago, I proposed an in-between solution called SessionLock [PDF]. This approach uses a combination of JavaScript and message-passing via the URL fragment identifier to cause every link, every AJAX request, etc. to be signed. Think of this as a more powerful version of HTTP Digest Auth that allows web sites to fully control login/logout procedures. The content of the web sites you visit with SessionLock is not protected. If you look at what your friends are doing on Facebook, someone with FireSheep might be able to see that, too. But, crucially, they wouldn’t be able to post new status updates, add friends, view data you haven’t viewed yourself during that session, etc. Is that good enough? I’m not sure, but I do think it provides a much more intuitive level of protection: when you’re on a public wifi network, you should always assume someone is casually looking over your shoulder. But you shouldn’t have to worry that they’re completely taking over your keyboard (I mean, that’s just rude!)

Shockingly enough, SessionLock has not caught on, and I often cry myself to sleep at night wondering why… Maybe it was too complicated? So, for those web sites thinking about what to do to respond to FireSheep, I propose SessionLock Lite. It requires a modern browser, IE8+, FF3+, Safari 4+, or Chrome, and it doesn’t fully protect against FireSheep, but it makes FireSheep’s stolen sessions valid only for a very short period of time (a few seconds). Could this be a reasonable compromise?

The idea is this:

• the web site, say facebook.com, logs you in over SSL the way it currently does, and sets a secure session cookie that is only transmitted over SSL.
• when the site redirects you to the plain HTTP site, the way it currently does, the plain HTTP site opens up an invisible IFRAME onto the SSL-protected version of the site.
• the SSL IFRAME computes, every few seconds, a new token that is timestamped so it is valid for only a few seconds. This is likely done using HMAC and the secure cookie as the key. HMAC can be computed in JavaScript in a few milliseconds.
• the new token is communicated to the containing HTTP frame using postMessage(), which is the main reason you need a modern browser.
• the containing HTTP frame then uses this token as its unencrypted cookie.

Effectively, the SSL channel is used to refresh the session cookie very rapidly, all locally in the browser, without making SSL requests to the server other than the initial request to a very small file when the page loads. This is particularly optimized for AJAX-heavy sites like Facebook and Twitter, where the SSL IFRAME will live on for minutes or hours. While you’re using the site, someone on FireSheep can use it, too. But the moment you stop using it, they can no longer use it either.

This is not anywhere near a complete solution, but it’s a very cheap solution that costs almost nothing performance-wise, requires changing very little code, and certainly reduces the damage FireSheep-wielding attackers can cause.

What happens next is going to be very interesting. The folks who have been fighting hard against Internet Voting should be careful not to use the same faulty logic they’ve been criticizing for years. When the discussion was about paper was electronic voting machines, some election officials said “well, *I*’ve never seen anything go wrong, show me an example!” And the answer we, computer security specialists, gave was some variation of “how do you know nothing went wrong?” or, in the words of Dijkstra, “Program testing can be used to show the presence of bugs, but never to show their absence.”

What reasoning applies, then, when we do find a bug? We are faced with an effective attack against a specific Internet Voting system. It’s easy to get carried away… Verified Voting just declared the Dangers of Internet Voting confirmed saying:

we have a visceral demonstration of just how serious the threats really are.

yes, so far I agree,…

But do legislators and election officials fully understand what Dr. Halderman’s team has taught us? We’ve been given a lesson on how easy it is for attackers to penetrate and control not just this system, but any Internet voting system.

Ummm, no. That’s incorrect reasoning. Remember the important question: how do you know? We know that this system in question is insecure. But we have no proof that all Internet Voting systems are insecure. This is the same faulty logic of inappropriate generalization we accused the election officials of only months ago!

Now, once again, I need to clarify: I agree that Internet Voting for high-stakes elections is deeply problematic, and I’m against it. Interestingly, I don’t think this server-penetration hack represents the inherent problem with Internet Voting, because, given sufficient work, we could probably secure a voting server. The core problem is that end-users’ computers can’t be secured, making it possible to defraud the election even if the server is very secure. But whatever I think, and whatever everyone else thinks, this particular hack does not prove anything about the security of all Internet Voting systems in general.

If we, as security professionals, attempt to leverage and over-generalize this one incident, we’re just as guilty of overlooking sound security reasoning to push a particular agenda, exactly what we saw some election officials doing in 2004-2006 with electronic voting machines. In the long run, this greatly undermines scientifically-based arguments against Internet Voting. The ends do not justify the means.

The Halderman DC Internet Voting Hack is not specific to voting: it’s a fairly standard input-corruption attack on a web application. With more work and more security testing, the voting system will probably get better and more difficult to attack. More consistent input validation, running the server chrooted to limit the effects of this kind of attack, etc. Much can be done to make the voting application more secure. But, as Halderman and team correctly point out, it will never be fully secure, because nothing ever is.

The first and obvious conclusion is that Internet Voting for high-stakes public-office election is a very risky proposition, because suddenly your world of eligible attackers includes anyone with an Internet connection. But there’s a deeper conclusion, and I find it surprising that many voting security pros don’t see this more clearly: when we say “every system is vulnerable to attack”, that includes paper-based voting systems! Without an internet connection, it’s harder to attack a paper-based voting system, but it’s still doable. And the key problem is that, when a paper-based voting system gets attacked, the recovery story is not much better than that of an Internet Voting system.

The best example of this sad state of voting security is one I learned from Alex’s previous work hacking the Indian voting machines: in remote precincts in India, with their paper-ballot voting system (prior to the recent Electronic Voting Machines that have resulted in so much controversy), there’s long a type of attack called “precinct capture,” where attackers literally hijack a precinct and take the staff hostage while they stuff the ballot box with extra votes. Then they leave. Oh sure, you know who did it. But what can you possibly do to recover? Which votes do you discard?

My friend and voting technology veteran Jim Adler likes to talk about “Fort Knox vs. Barking Dog.” If you think about security like Fort Knox, where you focus on preventing someone from penetrating your defenses, you’ve got to invest incredible amounts of money and build incredibly sophisticated fences. If your defenses fail, and someone penetrates Fort Knox, gets the gold, and leaves, you are screwed. Because it’s gold, it’s not traceable, and once it’s stolen, it’s gone for good and there’s no way to recover.

The Barking Dog model is different. You still build fences. Maybe even a fancy lock. But more importantly, you get a well-trained dog, maybe even two or three for redundancy. And you assume that some of your fences will fail, because that’s what fences do when faced with smart intruders. When they do fail, and someone comes in, that’s where the barking dog comes in. Your defenses may fail, but your detectors will sound the alarm, allow you to respond and, hopefully, recover from the intrusion.

So back to voting with our new-found Knox v. Dog wisdom. Can we get a “barking dog” model of voting? The main reason it’s not so easy is because of the secret ballot: we want to ensure that, other than you, no one knows how you really voted. Because of this simple requirement, it’s very, very difficult to detect a problem. Even with paper-based systems, the answer is “sort of” at best. There’s a bunch of fascinating research into optimal auditing techniques, but the problem with all of these techniques is that the dog barks only under certain conditions, and even then only way too late. By the time you find out that something bad happened, there’s no way to recover. Consider again the Indian precinct capture attack. What can you possibly do to recover from that?

The Barking Dog is only useful if it barks in time for you to do something about it. That’s why I am increasingly convinced that, now that we have the technology to build systems that can be truly audited by the public thanks to individual tracking numbers and cryptographic auditing techniques, all while preserving the secret ballot, it’s simply sound engineering to do so. With these open-audit systems, any voter can be a barking dog.

So, we should clearly rethink our attempts at Internet Voting in high-stakes public-office elections. But, by the same token, we should rethink all election processes that do not provide recovery from error or attack. Paper-ballot systems may be noticeably less vulnerable to attack than Internet voting systems, but once they are attacked, they are hardly more recoverable. Now that we know how to do better, we should not rely on a Fort Knox, impenetrable-fence model of voting security, even with paper ballots.

UPDATE: Jim dug up the archeological trail of the Barking Dog in voting technology: a VoteHere blog post referencing an MSNBC report on their technology. Also, typo fix and clarification regarding the Indian precinct capture attack.