Followup To Downloading Software Safely

5 March 2014 05:13 UTC

I’ve received some emails, tweets, and Hacker News comments about my post Downloading Software Safely Is Nearly Impossible. Thanks for reading and I hope you got a kick out of my mumblings.

I’d like to address some of the comments and questions people had, as briefly as possible.

• Yes, you need a trusted computing base (TCB). I alluded to this when I said “You’re pretty sure the NSA did not interdict it during shipment, and thus that it comes only with the flaky goatware Microsoft, Lenovo, and any number of Lenovo’s business partners intended for it to have.” Our goal as security engineers is to limit the size of the TCB. It is, after all, quite goaty already...

• The TCB includes the set of X.509 trust anchors for our TLS library.

• Yes, I harp on and on about HTTPS. That is because authenticating the delivery channel — while not necessarily sufficient to indicate code integrity — is the bare minimum effort we should require from our software sources. Especially for software that is related to cryptography and security. Here is GnuPG’s bug tracker; would you want to log into it or report security-sensitive bugs using it? :

• Also note that there are at least 2 different problems with HTTPS in that post: HTTPS not being available, and the HTTPS site differing in contents from the HTTP site. Again, for a software distribution site, we’d like something that smells a bit better.

• Some people claim that PGP keyservers don’t need to use HTTPS, because the keys authenticate themselves with the web of trust. And it’s true, the WoT does allow us to fairly easily distinguish this fake key from this real key for EFF’s Seth Schoen. But,

  • Seth is one of the most well-connected people in the WoT, so a key with only 1 signature stands out as odd. Would a fake key for a normal person stand out so well? The WoT is not as good an authentication mechanism as we might hope it to be. As nice as it is, verifying software packages based on PGP keys we grab from key servers is thus not a slam-dunk alternative to or replacement for HTTPS — and nevermind the usability delta between HTTPS and PGP.

  • By now, we understand that metadata for communications is at least as valuable as the contents, in many cases. Shouldn’t PGP users have confidentiality in their directory lookups? Yes.

• Yes, as many commentators noted, we should use something like Authenticode: binaries should be signed, and their signatures checked at run- or install-time. However, that still requires a TCB of code-signing trust anchors (the same companies that are your TLS trust anchors), and the difficulty for users of verifying the code authors is at least as difficult as verifying the authenticity of an HTTPS web origin. I.e., not super easy. Definitely better than nothing.

• This is an extremely hard problem, no doubt about it. Although my post is very snarky and sarcastic, I don’t think it’s an easy problem. I also fight the problem uphill.

• A big part of the solution is to isolate sources of code based on their cryptographic identity. This is how Android works, and it is how the open web works (when you use HTTPS or other authenticated origins). I’m not very knowledgeable about iOS, but I understand they also rely on code-signing and on sandboxing. If the isolation is strong, much of the risk is reduced — remember, a big part of my problem was that PuTTY (or any program) runs with the full privilege of my user account on the platform. Reduce the privilege, reduce the problem.

  • If course, now the problem is exposing a privilege-granting UI to users so that applications can share with explicit approval. One size does not fit all, and that continues to be a hard secure UX problem.

• Finally, I’m not really a fan of Web Crypto. I think more mistakes will be made with it than successes; it’s just that I also think that of native-code crypto. The problem does not lie with the implementation environment, but with the (often perverse) incentives developers have combined with the high level of expertise needed to use cryptography appropriately and well. Clearly, all the people who hope to use web crypto to replace TLS, implement DRM, achieve security against the server that sent the JS, implement homebrew challenge-response protocols, and so on are in for a heartbreak. But still, there are potentially good applications for cryptographic algorithms exposed to JavaScript, and native code does not have a privileged place in crypto. If anything, due to the lack of privilege separation in legacy platforms, native code is a worse place to put powerful code.