Benlog

security, privacy, transparency.

I was wrong about the iPad

Filed under: policy, security — January 31, 2010 @ 4:00 pm

So I made a couple of predictions about the iPad, Apple’s tablet, and I realize in retrospect that, while I got some of the details right, I got the gist completely wrong. I thought it was going to be a special-purpose device. And most commentators are saying just that. But I was wrong and they are wrong. The iPad is very much meant to be a new approach to how we use computers in general. Still think it’s just a big iPhone? Watch these few minutes of video, a summary of how you interact with the iPad to create slides and edit documents in Apple’s productivity suite:

This is different. Much more natural to use, a different experience altogether. It’s going to sell like mad, and developers will be building apps for this in no time.

The real Apple fanboys (I’m only a poser Apple fanboy) are saying almost what I’m saying: this is a new model of computing, the critics are suffering from future shock. Yes, and yes.

That said, the Apple fanboys are taking one critical step too many by accepting the hand-waving argument that this revolutionary computing model justifies the Apple-controlled App Store. Apparently, it’s like driving an automatic vs. a stick-shift, or better yet it’s like the Prius where you need special skills to maintain it. Spare me the kool-aid, these analogies are incredibly bad. If you really want to use that analogy, at least realize that adding your own app to a computer is more like installing a GPS on the dashboard, not tuning the engine. Would you be okay with a Prius if somehow you didn’t have the right to install Honda-made seat covers, or tires made by Michelin? Well, if the Prius were good enough, you’d grind your teeth and deal, but in what world would you argue that it’s a feature that you can only install seat-covers approved by Toyota?

Yes, the iPad looks amazing, and yes, it will sell lots, and yes, it will redefine the way we interact with computers. But would we lose any of those things if Apple allowed you to add your own applications? No. The Apple death-grip is entirely orthogonal to all of those wonderful things. There could be a scary-red toggle deep down in the preferences, or a magical swipe pattern, or a software download from the Apple site with a big fat warning that says “be careful, if you enable the ‘risky install’ feature, you may be forced to reset your iPad to factory settings.” Most people would use the iPad untouched, but the ability to open it up to other stores would bring more competition and would prevent the App Store overlords from making clearly anti-competitive decisions like rejecting the Google voice app.

So I was right about one thing: the iPad is going to move us one step closer to Zittrain’s dystopic Future of the Internet. But because the iPad is much more of a general computing device than I expected, that step is going to be a much larger step, and Zittrain’s vision is coming true much faster than I thought. And that part is incredibly sad, no matter how badly I want to edit slides using finger-swipe gestures.

Sometimes it’s not counter-intuitive

Filed under: crypto, security — December 27, 2009 @ 5:36 pm

Bruce Schneier writes that it’s reasonable for unmanned drones to broadcast unencrypted video streams, because

  1. the video stream is not that useful to enemies, and
  2. given that many people need access to the video feed, the key distribution problem would be very difficult to manage, and some allies could be severely handicapped if they happened not to have the key.

So, Bruce is typically fantastic at finding those interesting areas of security where the answer is counter-intuitive. But huh? How can both of those points be true? If the video stream is valuable to allies, then I’m guessing it’s valuable to enemies.

But let’s say that, somehow, these contradictory points are, in fact, both true.

There isn’t a key management problem here. The command-and-control signal is already encrypted and authenticated, so the video feed could be encrypted via the same exact route back to the home base (which needs to happen anyways so the NSA pilots can, you know, pilot), at which point it is decrypted and can be syndicated to allies, troops on the ground, commanders, etc… I just don’t see the argument for the signal to be directly received by local troops, when the one person who needs the signal the most anyways is already sitting thousands of miles away.

Bruce is right that key management is often a very complicated problem. But I just don’t see how it’s relevant in this case.

a prediction regarding the Apple “Tablet”

Filed under: autonomy, policy — December 26, 2009 @ 8:31 pm

Why a prediction? Eh, cause it’s fun and cause I think the Apple Tablet will have a large impact on consumer computing.

I think Apple will launch a tablet computer in January that will be aimed at saving TV and print journalism. On-demand video and on-demand print magazines and newspapers will be at the forefront. And because those industries want Digital Rights Management, the Tablet will run the iPhone OS so that only approved apps can be installed. It will be great, and the “App Store” concept will continue to rock the house.

In the meantime, Zittrain’s Future of the Internet will be one gigantic step closer, with consumer computing devices tightly controlled by one benevolent dictator. For most people, this will be a very good thing. For innovation, this will be a very bad thing. But it may take a while before people miss it. After all, did people miss Skype before they ever knew it was possible?

Happy 2010, and here’s to hoping we can come up with safe and generative software platforms.

Takoma Park 2009: the conclusion

Filed under: Takoma Park 2009, crypto, voting — December 23, 2009 @ 9:20 pm

Well, it’s been a few weeks of craziness at home and catching up on other work, but I’ve finally wrapped up the Takoma Park 2009 audit. The final step: letting you, dear reader, run the audit all on your own.

You’ll find the complete instructions here on the auditing site.

I haven’t tested this on Windows, just Mac OS X, and it should work on Linux/Unix, too. You need Python 2.5 or above, PyCrypto, git, and subversion. You need about 30 minutes of download time, and 1 hour of processing. And then you can check the results you’ve computed against the results I’ve computed, against the official election results (which have some small variations since the results were certified, I’m not entirely sure why), and against the list of verification codes.

It’s a WRAP followup: maybe the goal was client-side certs?

Filed under: security, web — December 23, 2009 @ 2:48 pm

I’m having some interesting offline followup discussions with folks about oAuth WRAP and my relatively negative reaction to it. One of the comments seems to be that SSL will recreate exactly the security that HMAC signatures were trying to achieve, and it was really hard for developers to do oAuth right in the first place.

I definitely sympathize with “it’s hard to get security right,” and I certainly agree that we should begin to standardize oAuth libraries ASAP. The reference implementations are okay, but they’re not solid enough for widespread standardization, which means people are cooking up their own, which is bad news. So yes, being able to delegate the security implementation to a well tested library is a good idea.

But I don’t think server-side SSL replaces the security we got from HMAC-signed requests. The key idea of signed requests is that if I intercept a request, I can’t steal the credentials. The only way SSL compares is if certificates are definitely checked or if client-side certificates are used for authentication. I don’t buy the argument that oAuth WRAP client-side libraries will do proper certificate checking. And I think that, while very cool, client-side SSL certs would make life potentially more complicated for developers (and would rule out JavaScript implementations for the foreseeable future.)

I’m very open to the idea of simplifying oAuth, and maybe there’s something to oAuth WRAP that I’m not seeing…. but the point is, the current oAuth WRAP security claims are, I believe, misguided in practice, and I hope the oAuth WRAP team thinks this through a bit more before all the big name web sites standardize on it, and the next favored technique for hacking your Facebook account is DNS spoofing the oAuth WRAP transaction.

It’s a WRAP

Filed under: security, web — December 22, 2009 @ 1:58 pm

I’m just finding out about oAuth WRAP, a new, simplified version of oAuth which some are calling the “valet key” approach to web data sharing: don’t give your Facebook password to a random web app, instead use oAuth to mint them a valet key that lets the app access only some specific portions of your Facebook profile. I like and use oAuth, so I was a little bit confused as to what WRAP brings to the table. I read up a bit:

The main difference between OAuth and OAuth WRAP is that WRAP does not have elaborate token exchanges or signature schemes. Instead, all server-to-server WRAP calls happen via SSL. The “access token,” which grants your client the ability to make API calls on a user’s behalf, is protected by SSL rather than by a shared secret and signature scheme.

If I understand correctly, the experience is the same for the user, the connectivity requirements between the data host and the third-party consumer remain the same, but now we’ve gotten rid of those pesky signatures and instead we’re sending tokens in an HTTP header a bit like a password.

So, like a password, it can be replayed. And intercepted via Man-In-The-Middle. Oy.

But wait, you say, don’t worry, the token is sent over SSL, so it’s all good.

Right. What’s going to happen when someone “forgets to turn on SSL”, which is all too common when security is abstracted out “somewhere down in the stack.” Or when we stop dealing with those pesky certificate errors and just choose not to validate the cert, which will leave the protocol wide open to network attackers who can now literally play man-in-the-middle just by spoofing DNS on a wifi network, capturing the token, and replaying it to access all sorts of additional resources, effectively stealing the user’s credentials.

This might actually be worse than passwords, because at least you can work to educate users about SSL (and after their Facebook account gets hacked, they might actually care), but it’s very hard for users to gauge whether web applications are doing the right thing with respect to SSL certs when the SSL calls are all made by the backend which has trouble surfacing certificate errors.

I understand. Security is hard. Getting those timestamps and nonces right, making sure you’ve got the right HMAC algorithm… it’s non-trivial, and it slows down development. But those things are there for a reason. The timestamp and nonce prevent replay attacks. The signature prevents repurposing the request for something else entirely. That we would introduce a token-as-password web security protocol in 2010 is somewhat mind-boggling.

I see reasons to simplify oAuth. Maybe rethink the combination of consumer and access secrets, which is a bit messy. Maybe rethink the token renewal process and make it part of the core. But removing signatures? I think this is asking for long-term trouble in exchange for a modest amount of short-term simplicity.

Facebook account hacked

Filed under: security, web — November 11, 2009 @ 1:17 am

So this evening my Facebook account was hacked and spam messages were posted to a few dozen friends on my behalf. Thankfully, since I’m friends with a number of security-savvy folks, I was notified almost instantly. Now I’ve never cared too much about my Facebook account, so I used one of my weak passwords. I’m pretty sure I wasn’t phished, and I’m pretty sure I don’t have malware installed on my machine, so I’m guessing (as suggested by Aaron) that some site where I reused my weak password was hacked…. but which site? Who knows. Maybe it’s really time for me to fully address this web-password situation with a real solution.

So I’ve been working on cleaning things up at Facebook. And I’m a little bit surprised that Facebook doesn’t make it easier for you.

  1. I changed my password, but I’m wondering, does this invalidate all currently open sessions? I hope so, but it would be nice to know.
  2. I removed a few apps that I haven’t used in a while, though I’m pretty sure that apps can’t do wall posts.. but still it would be nice to know for sure, and it would be nice to have one page from which I can remove a bunch of apps, which doesn’t quite seem possible except if you’re only interested in removing recently used apps.
  3. I never write on people’s walls, and yet Facebook allowed my account to write on dozens of walls in a matter of seconds without throttling. Seriously? How about a CAPTCHA or an email confirmation or heck the ability for me to say “lock my account if I post more than 3 wall messages in a minute”. I understand that not all users want to be throttled, but I care about not spamming my friends, so I would opt for the “more secure” version of Facebook that inherently limits my abilities so that my friends are mostly spared if I get hacked.
  4. I’d like to see all of my wall postings so I can delete them easily from one page, but I can’t seem to find a page that lists those, I have to go through my “recent activity,” and when I click the “X”, I’m not sure if I’m removing the post from my friends’ walls, or just removing the entry from activity log, so to be safe I clicked through to each friend’s wall and removed the post there. “Tedious” comes to mind.
  5. I’d like to see everything that happened in that bad session, and maybe even what IP address / web browser was used, so I can trace and see if they tried to log in before, etc…

If there are any Facebook security engineers listening, it would be great to be empowered to clean up our accounts more easily. Right now, I feel quite powerless, I don’t have the tools to clean things up, and I don’t even know if I’ve finished cleaning things up completely.

UPDATE: oh great, now Facebook suspends my account, though I’ve already changed my password to a stronger one, I need to change it again. And now I’m wondering, when was the suspicious activity detected? After I cleaned up? If so, is it still happening? More info Facebook, please, more info.

Takoma Park: verifying the shuffle and the unopened ballots

Filed under: Takoma Park 2009, crypto, voting — November 9, 2009 @ 7:29 pm

So the votes have been cast, the uncertified tally has been released, and the confirmation codes have been published for all voters to check. Now, it’s time to make sure that the coded votes, which were shuffled via the Shuffle Tables into the decoded votes in the Results table, were indeed shuffled and decoded correctly.

Having trouble remembering which table is which? Here’s a reminder:

pdr-setup

Now of course we don’t actually see these tables in cleartext, rather what we have right now is:

pdf-vote-cast

Next, the Scantegrity team used random stock data to seed a random number generator and decide which side to open up, the left or right. Now we said before it would be row-per-row in the shuffle table… but because of a subtle privacy issue, it turns out instead that there are 40 Shuffle Tables, and each one will be open either entirely on the left, or entirely on the right.

That’s what was done, and that’s what I verified just now in the Meeting 4 Audit.

Any Issues?

The same issue that I mentioned for Meeting 2 applies: the stock-data program pulls data that is, unfortunately, still being adjusted for a few days as stock trades reconcile, and thus it’s not possible for me to find the exact same seed. I have to trust that the Scantegrity team did it right. Not ideal, as I mentioned before, but also not extremely worrisome because the other parts of the audit provide a bit of insurance against any error here: next we’re going to open up every piece of data for the unused ballots, and there are a lot of those, and no carefully crafted randomness can hide cheating here.

Contested Ballots?

Scantegrity supports a “contested ballot” audit where, if a voter wants to contest that their confirmation code does not appear, all confirmation codes for that ballot are opened up to prove there was no hanky-panky. Since that original nomenclature, the Scantegrity team has decided to effectively act like *all* ballots are contested by default, so that all confirmation codes for all cast ballots are revealed to prove that there are no duplicates or other naughtiness. Of course, the correspondence between confirmation code and real, decoded candidate is not revealed.

If you voted in the Takoma Park election, you can check your ballot’s complete set of confirmation codes against my regenerated list.

Auditing Unused Ballots

For all ballots that were unused, the Scantegrity team is now forced to reveal all of the shuffle table rows and all of the confirmation codes. Since it’s not possible for the Scantegrity team to predict ahead of time which ballots would be used and which would remain unused, this audit gives us added confidence that the used ballots were okay, too, because the unused ones are.

Check out the Unused Ballot Audit. Everything checked out fine.

So… are we done?

Yes, we are! It looks like the Takoma Park election went well, and I can say with confidence that, if you voted in the election, wrote down your confirmation code, and checked it against my copy of the confirmation codes, then your vote counted the way you intended it to. And I can say this even without knowing how you voted. Pretty darn cool.

Over the next few days, I’ll write up a couple of followups regarding:

  • some recommendations for improving Scantegrity,
  • an explanation of what happens if the election officials are all corrupt, and
  • a script that lets you re-perform the entire Scantegrity audit on your own.

The first good mainstream article on vaccines in a while

Filed under: health, policy — November 9, 2009 @ 10:48 am

I meant to mention this a while ago, but I keep forgetting. Amy Wallace at Wired wrote a fantastic piece on how irrational fears of vaccination are putting us all at risk. The feedback to Ms. Wallace has been enormous, and although tilted towards the positive, the negative feedback from the anti-vaccination crowd is insulting, misogynistic, ad-hominem crap.

I’m a scientist and engineer, but I’m not a medical doctor. Back in 2004, when Robert Kennedy Jr. published his anti-vaccine piece in Salon/Rolling Stone, I worried that there was something to his claims. I asked around. I’m lucky enough to work with some of the world’s top pediatricians, and to be married to a fantastic doctor and geneticist, so I had plenty of expert resources to turn to who set me straight. Not everyone has access to that level of expertise, which is why it is so morally reprehensible for those like Robert Kennedy Jr., Jenny McCarthy, and other know-nothings to be falsely leading those who have no one to set them straight.

And that’s why Ms. Wallace’s article is so crucial. It lays out, in plain English, exactly why vaccination is so important, and exactly how the anti-vaccination movement has shifted its story every time scientific evidence made their claims just too darn difficult to stand by.

Don’t have time to read that great article? Here’s the one fact you need to know: the anti-vaccination crowd kept harping on thimerosal, a vaccine preservative, as the culprit, claiming it was causing autism. Except, in 2001, thimerosal was removed from all childhood vaccines, and autism rates kept going up unchanged. That’s when the anti-vaccination movement changed its tune to “too many too soon”, and to the insane claim that vaccines contain anti-freeze (which would be true only if “ethyl” and “methyl” were the same chemical prefixes, sucks to be precise.)

Also, if you are a scientist, even if you aren’t a medical scientist, take the time to educate yourself briefly on the risks of the diseases we’re talking about, on the failure rates of vaccines, and on the multitude of studies that have shown no statistical link between vaccines and diseases like autism. It doesn’t take an MD or a PhD to figure it out. We need rational thought. Speak out. Don’t let irrational thinking flourish. Defend science, defend rational thinking, you’re not a Big Pharma shill just because you think vaccines are a good thing.

Read Amy Wallace’s article, and follow her on Twitter. She could be the breakthrough voice in this fight for rational thinking in public health.

Takoma Park: auditing the auditor

Filed under: Takoma Park 2009, crypto, voting — November 6, 2009 @ 12:37 am

Rick Carback from the Scantegrity team just pointed out to me that my totals are not quite the same as theirs, and he surmises that I may have read the Instant Runoff rules incorrectly. Specifically, my code considers that ballots that skip a rank, i.e. that go directly to choice #2 and never indicate a choice #1, are “exhausted”, meaning they don’t count anymore. In fact, the rules for Takoma Park state that, in that case, the next candidate choice counts, but if two choices are skipped, then it’s exhausted. He’s absolutely right, and I’ve updated my tally code appropriately, and now my numbers match….

Except for one more detail: the Scantegrity team is continuing the Instant Runoff candidate elimination past the point of a candidate gaining absolute majority. I think that’s wrong. It doesn’t affect the outcome, but it does affect the final tally count, so we’ll wait and see what the official word is.

In any case… isn’t it cool that we can audit each other and work out these differences with public code, public results, and complete oversight from anyone who wants to watch? That, again, is the power of open-audit elections using systems like Scantegrity or Helios.