Just two weeks (to the day) after presenting Cloud & Control at RSA in San Francisco, I was in Amsterdam presenting at Black Hat EU. I've been getting more involved with the tremendous number of standards bodies and keeping track in my own head on what improvements are coming down the pipe - I decided it'd be worthwhile to quantify that in a talk (and whitepaper). The talk actually only brushes over some of the topics that I thought would be the most interesting to talk about - the whitepaper and slides contain way more info.

According to my filters, I'm on over 50 mailing lists and keeping track of everything is a pain - so I did it for you. The whitepaper, available here, covers a lot of topics. Improvements in and coming soon to browsers like Content Security Policy, Caja, Strict Transport Security, and Key Pinning; achieving authenticity through DNSSEC; and huge sections on TLS and PKI. I go into detail on TLS 1.1 and 1.2 including implementation issues, deployment, and why we'll never actually get the security of the protocols until we remove backwards compatibility; but also upcoming TLS changes like False Start and Next Protocol Negotiation. A couple larger topics in TLS like Channel Binding and Secure Remote Password, and a lot of smaller topics like Datagram TLS and Encrypted Client Certificates. Finally, I survey all the proposed fixes or replacements for the Certificate Authority system, from the very popularized like Convergence to the very obscure like YURLs. I pull out all the core concepts from the proposals to come up with a list of properties that can be used to evaluate all of the proposals and see where each falls short.

I put way more effort into the whitepaper than I think Black Hat expects, but once I started working on it I wanted it to be complete. It's likely to have some changes made - the current version is dated March 15, 2012, and is the first revision, containing a typo fix and a minor correction relating to RFC 5705 thanks to Adam Langley.

Update: The video has been posted by Black Hat. 160MB MP4.

Calyx Institute, Nick, et al

I can't express how impressed and inspired I was by Nick's prolonged legal battle. His willingness to stay the course, challenge the system meaningfully, and effect change is an inspiration to anyone who considers themselves a free speech advocate.

I want to make The Calyx Institute aware of a severe deficiency online, and hope to inspire you to do what you can about it. There are a number of individuals, nonprofits, and organizations that have run free-speech programs and services for years. But this has always been done ad-hoc, often resulting in problems and headaches. Services like Tor and remailers do generate legitimate abuse complaints. But these abuse complaints are often automated and ultimately do not stand up to the safe harbor provisions as a common carrier.

But that doesn't mean that Tor operators aren't forced to bounce hosting providers often. There doesn't seem to be any meaningful way for people to host these services without worrying at night about whether it will be there in the morning [1]. I won't confess to completely understanding the landscape of ISPs, ARIN, peering, and abuse contacts - but I do know there seems to be no way as an individual or even non-profit to find a reasonably priced host that supports free speech. I'm not looking for a host that turns a blind eye towards illegal activity, just one that understands that abuse notifications sent to a common carrier often have no teeth, and will pass them along to be dealt with by the individuals running the services.

I think the Calyx Institute, having been founded by someone who does understand the landscape, is uniquely situated in this area. It's not so much a matter of providing advice, as for years we've all talked to hosting providers until we're blue in the face - and still we got dropped by our providers. I hope Calyx Institute can grow to actually provide or partner with someone to provide the service, uplink, IP addresses, or whatever is needed to let individuals and organizations host our legal free-speech services. And give us the peace of mind to fight our own battles against corporations and the government - without also fighting our hosting provider.

-tom

Cosignatures:

• https://www.torservers.net
• https://crypto.is/

[1] You can browse the torservers mailing list archives for some insight into the problems. http://www.freelists.org/archive/torservers/

I gave my first presentation at a security conference on Friday, presenting at ekoparty on some work I did at the beginning of the year on distributing complex tasks to hundreds or thousands of computers. SETI@Home was the project that pioneered the idea of distributed volunteer computing, and their command & control software evolved into a generic project called BOINC. You can run just about any application in BOINC - whether it's open or closed source, uses GPUs, the network, or even if it's not CPU intensive (like nmapping the internet).

Setting up a server isn't the most exciting topic to talk about, so I used two examples to illustrate BOINC in my presentation: factoring RSA512 to recover the private key to SSL certificates or PGP keys and cracking passwords. Factoring was a huge success, but cracking didn't work out that well. BOINC was able to distribute the work and crack things really quickly - by splitting up wordlists automatically based on hash functions I was able to scale out to more machines than I think most people are able to... but the problem came from never actually looking at the output. The best crackers, especially in cracking contests, find patterns in the cracked passwords to make mangling rules and masks and crack more passwords. You could still use BOINC as a work distributor to scale out, but you need to be behind the wheel making work units - not use it as a fire-and-forget system.

Getting applications running in BOINC is a bit of trial and error. If it's an open source application, you have to patch it a little bit and if it's closed source you have to write a job.xml file defining how to run the application. In either case you have to define input and output templates that let BOINC know what files to send with the workunit and to expect the program to produce. And when I was sending a couple hundred MB wordlists and resource files, I wanted to compress them and decompress them on the client, so that added a little bit of work too. To try and make it easier on you, I've released all the scripts, templates, config files, and patches I created while working with BOINC. I've also not just released my slides, but annotated them with links to the reference material for everything mentioned. Everything is up on github.

I've wanted to factor large numbers for a while, and this was actually what got me into this whole mess. I have some (simple) observations about factoring using the General Number Field Sieve, as well as instructions for how to do it yourself (with or without BOINC).

I have to thank Leonardo and all the ekoparty organizers for putting on a great conference. They went out of the way to make the international arrivees as comfortable as possible, and even had simultaneous translation from english to spanish and from spanish to english. Buenos Aires is a wonderful city, and I really recommend you visit!

This writeup originally appeared on the Gotham Digital Science blog.

I just got out of Dan Kaminsky's talk at Black Hat where he talked about a myriad of topics, but the one I want to focus on was his tool Phidelius. It's a library you reference with LD_PRELOAD that hooks /dev/random, /dev/urandom and some other functions that un-randomizes the random data that key generators like gnupg, openssl, or ssh-keygen uses.

Why would you want to do that? Well, instead of using a random stream of bytes - it uses a reproducible stream of bytes based off a password/passphrase. The bytes could come from any key derivation script, but both Dan and I chose scrypt, by Colin Percival.

His tool is considerably more robust than mine and works with many different programs without modification - mine specifically generates OpenPGP keys. And as he noted in his talk - while you can do this - that doesn't mean it's a good idea.

The idea has probably been public for some time now, although I couldn't find an example of - and since Dan has shouted it out, I figured now's the time to release my code and let people play with it while they're interested. Anyway, there are a ton of caveats, some of which I'll list:

• This is pre-alpha. There may be straight-out-bugs in my code.
• Two people using the same password and scrypt keys would generate the same public keys. I think this is less of an issue than Dan, I assume people using my code would use strong passphrases.
• While it works and is usable, it relies on a bunch of tricks/hacks.
• The public key generated has a different KeyID each time, because the KeyID is a has over the public key parameters, which includes the date it was created.
• This may generate keys +/- a few bits off the stated length (2047 instead of 2048)
• The key generated is unencrypted - meaning there's no passphrase on your secret key.
• You'd have to have a crazy threat model for this to be a good idea.
• You don't have that threat model, and if you do, you still shouldn't use this code in real life.

The code is located here.

I am not a lawyer, and this blog does not constitute legal analysis. It should be taken merely as speculation and pointers to topics for you to do your own research on. Throughout this blog post I'm going to use this notation to indicate a word has a specific legal definition, and I'm not using the word colloquially.

One of the biggest targets of armchair lawyers on blogs, twitter, and reddit (myself included) has been whether or not the government can force you to turn over your encryption key. An actual lawyer, a law professor in fact, has written a series of posts on the theory, and details of the two cases that address the issue.

1. Encrypted Hard Drives and the Constitution - August 23, 2006 - The first time the question is raised, in a purely hypothetical way. It lays some information down you should fully grok - for example Miranda rights don't apply in many cases because you are not in custody and the 5th Amendment does not apply because you are not being compelled to produce testimony. It references the 1988 Doe vs United States case which addressed the question of applying the 5th Amendment to physical evidence (like a key to a safe) and to communication (like a memorized combination to a safe).
2. Court upholds using the Fifth Amendment to refuse to disclose your password - December 15, 2007 - The first post regarding an actual case, United States v. Boucher. The U.S. District Court for the District of Vermont held that Boucher could invoke the Fifth Amendment and refuse to comply. It again goes into detail about testimony and custody.
3. 5th Amendment Bummer - March 06, 2009 - An update on United States v. Boucher. The Government appealed, and modified their request. Now they were no longer after the password, but instead were trying to compell Boucher to show the unencrypted files to a Grand Jury. They crucially changed the argument from communication (exempt via the 5th amendment) to producing physical evidence (not exempt, see Doe vs United States 1988). The court bought the new argument and stated Boucher must produce the unencrypted contents by the date specified or be held in contempt (which amounts to sitting in jail until you comply).
4. Passwords and the 5th Amendment Privilege - April 28, 2010 - This post addresses U.S. v. Kirschner a case in the U.S. District Court for the Eastern District of Michigan. The government erred in this case by specifically seeking testimony and even using the analogy "It's like giving the combination to a safe." which we mentioned earlier was protected. The government's subpoena was quashed.

Now, updates on those two cases. According to the headline article "Boucher eventually complied and was convicted." Brenner speculated the government would appeal to the 6th Circuit in Kirschner (and based on the Obama adminstration's judicial actions I would expect so too), but I haven't been able to find any evidence of that - so I'm not sure what happened to Kirschner.

Now let's examine the current case - US vs Fricosu. It's in the United States District Court for the District of Colorado. I'm not sure how Fricosu is represented, but the case gained attention after the EFF filed an amicus brief in the case Friday. If you're unfamiliar with the term, it does not mean the EFF is involved in the case or representing Fricosu, only that they're interested in it and presents a supporting arguement to the court on behalf of Fricosu.

Now, again, I don't know the exact request made by the prosecutor, but quoting the article:

Prosecutors stressed that they don't actually require the passphrase itself, meaning Fricosu would be permitted to type it in and unlock the files without anyone looking over her shoulder. They say they want only the decrypted data and are not demanding "the password to the drive, either orally or in written form."

As we saw in Boucher, this doesn't bode well because they're taking the physical evidence approach. The best-case scenario is the prosecution argues the physical evidence approach and the court strikes it down. We'll have to wait and see. Now the EFF argues in their Amicus Brief that producing the decrypted contents should not be required, because doing so is testimony. Specifically, the government has not shown that Fricosu has control or knowledge of the contents of the laptop, therefore by decrypting the contents she is testifying to authority. (This has to do with the legal term forgone conclusion.) You should definetly read the brief as it goes into a lot of precedence and case law. It's also worthwhile to note that in Boucher, the contents of the encrypted drive were a forgone conclusion as Boucher has previously revealed them to a Customs officer.

But there are some other evidentiary issues here. You should definitely take this with a grain of salt - I've read Law School Evidence books, and did not do well on the practice tests. With computer cases, there's a lot of chain of custody, verification stuff that's got to be done. Image the drive, use a write-blocker, show the chain of custody that it couldn't have been altered... But the process they are describing would shoot the normal evidence handling process to hell. It'd be near-impossible to satisfy both sides.

Consider the case where Fricosu enters the password into a specially built program that's designed to decrypt with write-blocker and preserve evidence. Fricosu would have a strong argument the government could actually obtain the passphrase from her via subtle means. (I'm assuming the drive in question is the boot drive on a laptop - if it was a truecrypt container, the scenario changes.) While there may be assurance the evidence wouldn't be altered, there is none the government isn't taking the passphrase. (Now there could be some shenanigans with the government granting immunity for the passphrase but not the contents... I'm not sure how that'd work.)

Now consider the case where Fricosu enters the passphrase for the laptop in court in front of the grand jury - no write-blocker involved and no protections in place. Fricosu would have an argument that the evidence could have been altered and should not be admitted (e.g. by normal operating system boot-up, or a malicious virus on the machine, or simply by a script she wrote to delete sensitive files on startup). These issues can be overcome by the court, but they are argued on their own. Brenner has written articles in this area as well. On this topic, it'd be trivial for me to write a startup script on my machines that says "Have I been turned on in the last 2 months? No? Okay, shred all the sensitive stuff...."

Another nice thing about this case is that unlike Boucher and Kirschner; Fricosu isn't accused of child pornography. I imagine it's difficult for lawyers to argue civil liberties when the individual you're protecting is rather obviously someone involved in transporting or concealing child porn. Certainly there are arguments that everyone deserves a fair trial - and they do... but there's also the reality of the crime.

Update: July 20, 2011 Susan Brenner of the previously super-linked cyb3rcrim3 has graciously obtained the government motion in the case, sent it to me, and allowed me to post it before her. You can download the pdf here or view it in google docs.

The motion doesn't go into details about what type of encryption software was used, but do imply that the entire computer is protected - so probably PGP WDE or Truecrypt. It gives several details that apply to the arguement of whether or not Fricosu has control or knowledge of the computer, and also directly says:

As the act of production might potentially entitle Ms. Fricosu to assert her right to refuse under the Fifth Amendment of the United States constitution, the Government has sought approval to seek this court's grant of limited immunity, thus precluding the Government using her act of producing the unencrypted contents against her in any prosecution.

One of the last arguments made by the EFF in their amicus brief is that Fricosu is justified in refusing to provide the password because that limited immunity does not include a "guarantee against use or derivative use of the information". That is:

When a witness's act of production is testimonial in character, the government must grant use and derivative-use immunity to satisfy the Constitution.s requirements. Hubbell I, 530 U.S. at 41-46. This means that the government may not use the act of production itself against Fricosu, nor any evidence on the computer derived from the act of production. ... Should the Court decide that Fricosu must supply the data on the laptop in decrypted form, the government will face a .heavy burden of proving that all of the evidence it proposes to use [from the laptop] was derived from legitimate independent sources. (emphasis mine)

The strongest argument is this: "I do not believe he can be compelled to reveal the combination to his wall safe". But where does it come from? From the Supeme Court Case Doe v United States 487 U. S. 201 (1988). But it wasn't the major finding of the case. Rather, it was made in two places. Second, most plainly, in a comment by Justice Stevens in a dissenting opinion: "He may in some cases be forced to surrender a key to a strongbox containing incriminating documents, but I do not believe he can be compelled to reveal the combination to his wall safe -- by word or deed." And the first, a weaker one, in an implication in a footnote of the Majority Opinion:

We do not disagree with the [prior statement] that "the expression of the contents of an individual's mind" is testimonial communication for purposes of the Fifth Amendment. We simply disagree with the [prior conclusion] that the execution [at issue here] forced petitioner to express the contents of his mind. In our view, [the compulsion] is more like "being forced to surrender a key to a strongbox containing incriminating documents," than it is like "being compelled to reveal the combination to a wall safe."

I heavily hacked that up to make it easier to understand absent details of the Doe case, you can see it in the original form by searching for "wall". But lawyers are really good at this. The majority opinion did not say that the wall safe was protected speech like Stevens did, only that this instance was unlike a wall safe. I think it's plain to see that a wall safe is a very good analogy for encryption. They're not perfect - but a very good wall safe could not be opened forcibly without destroying the papers inside, and good encryption cannot be opened reasonably. We have to hope the court finds that producing the contents of a wall safe or encrypted container would be an "expression of the contents of an individual's mind".

Now I wonder about keyfiles. If the government didn't know how to unlock a truecrypt container, they could try to compell you like this. But there is no password. And you tell them this, you tell them it is unlocked with a keyfile. So they demand you produce the keyfile. Here's where it gets tricky... Could you say "You have the keyfile already, and my telling you which one it is is protected."? You can't prove they have the keyfile without giving it to them - there's no zero-knowledge proof possible here. Any attempt to construct one would fail because no judge would accept the rigor required for a zero-knowledge proving. I wonder how keyfiles would be treated...

I expect to update this over the next few days as details emerge. Updates will not trigger a new RSS entry, but will be announced on Twitter.

if 1 * 2 < 3:
    print "hello, world!"