COMSEC: January 2008 Archives

 

January 26, 2008

News is circulating of a German plan to build a "Skype-Capture-Unit", software which would live on your computer (be surreptitiously installed by the government) and capture the media for analysis. This is necessary because Skype is encrypted so ordinary capture mechanisms just get ciphertext. It's a little hard to read what's being proposed, but it sounds like the software would actually divert a copy of the plaintext to the monitoring station.

If this is indeed what the German government is planning on doing, it's actually kind of lame. First, it's inefficient since you need twice as much bandwidth, for the original media stream and the copy to the monitoring station. Second, it's easy to detect, because you're using a lot more bandwidth. An approach while would be much harder to detect would be to arrange to leak the encryption key and then capture the ciphertext using standard monitoring techniques. The key leakage can be done in such a way that it's very hard to detect.

The document also describes an SSL interception system. I'm finding it a little hard to decode, but it talks about a man-in-the-middle attack, which also easier to detect than necessary. Again, this doesn't seem like the most efficient technique—easier to just leak the keys.

As I've mentioned before, since Skype controls the software, they could assist the government with LI if they chose. This document is at least suggestive that they're not doing that.

 

January 24, 2008

As you may have heard, the FISA telecom immunity bill is back. If you haven't heard, the administration is pushing a bill that would, among other things, provide retroactive immunity for telecoms who participated in the warrantless wiretapping program. A few months ago when this last up for debate, I wrote to Dianne Feinstein about this. Probably not uncoincidentally, I got an email from her office about this the other day:
The Intelligence Committee's report on the bill includes declassified text stating that the Executive branch provided letters to electronic communication service providers at regular intervals. These letters all directed or requested assistance and noted that the assistance was authorized by the President and was legal. The Committee's report can be found at http://intelligence.senate.gov/071025/report.pdf.

I introduced an amendment on the Senate floor that would limit this grant of immunity. Under my amendment, cases against the telecommunications companies would go to the FISA Court for judicial review. The Court would only provide immunity if it finds that the alleged assistance was not provided, that assistance met legal requirements, or that a company had a good faith, reasonable belief that assistance was legal.

This seems like a pretty low bar. There are actually three cases:

  1. The telcos thought that they were legally required to enable wiretapping.
  2. The telcos thought that they didn't have to enable wiretapping but that it was legally permitted.
  3. The telcos thought that they were legally forbidden from enabling wiretapping.

The basic rationale for immunity seems to be that the telcos thought they were doing their civic duty and shouldn't be punished if it turns out that it was actually illegal (note that this stance is a bit belied by the much-publicized revelation that the telcos stopped the wiretaps when the government didn't pay). This isn't crazy: certainly, if the telcos were in receipt of a court order directing them to wiretap some set of communications I would expect them to comply (though a telco which was known to have actively resisted the order would certainly be one I'd want to give my business to) and a grant of immunity seems reasonable in such a case—though I'm not sure that one was required. So, if the telcos can demonstrate that they actually had a good faith belief that they were legally required to comply then immunity seems appropriate.

Similarly, if it turned out that the telcos thought they were actually violating the law then immunity seems totally unreasonable. On the other hand, it would be fairly unsurprising if they were stupid enough to leave records lying around that said "let's do this totally illegal thing." Is there anyone who thinks that they should have immunity in this case? (This isn't to say that the law as currently proposed doesn't grant immunity here—I haven't checked—in which case Feinstein's amendment would be an improvement.)

So, case (2) is the interesting case: the telcos thought they had some discretion and decided to exercise it in the government's favor and not that of their customers. That's certainly a reasonable business judgement and of course there are powerful reasons for getting on the government's good side, but getting sued and losing a lot of money in case what they've decided to do is actually illegal is the business risk you take in such cases. If you want (and I do) the telcos to take any interest at all in your privacy, then they actually have to bear some risk in cases when they decide not to do so.

That said, whether the telcos get punished is actually not the most important piece here. As I understand it, one effect of the immunity grant is to effectively foreclose a lot of the lawsuits currently filed against the telcos. Since those suits were a major avenue for public discovery of what really happened in this program, the immunity grant would also act to keep the details of the program secret, which is bad if you think that this is the kind of thing that ought to be publicly discussed rather than just done in secret. I'd be much more receptive to a bill which granted immunity in return for full disclosure, but of course that's not what Feinstein's amendment does, since the immunity determination is made by the FISA court.

 

January 9, 2008

The reason that front running works at all is that WHOIS leaks the name of the domain you're looking to the WHOIS service operator and in this case the operator is the adversary, thus giving them an opportunity to get ahead of you. The usual answer to this problem is to create a set of policies that treat WHOIS queries as sensitive information (see ICANN's study on front running). One could, for instance, require the WHOIS operator to treat WHOIS queries as private.

However, there's a cheap, compatible, technical hack that substantially increases the difficulty of front running attacks without any new policies: allow WHOIS searches on hashes of domain names. The way this would work is that the WHOIS operator would create a parallel tree of phony domain name registrations in WHOIS. For instance, if I registered example.org, then they would also create an entry for SHA-1(example.org)=20116dfd6774a9e7b32eddfea3f6cb094e38fc3f.org (we might need to register a new TLD to make this work and guarantee no collisions) and populate it with the record for example.org. Then, I could locally compute the hash for each domain name I wanted to check on and easily verify its existence or nonexistence.

Other properties:

  • The WHOIS server doesn't get the name being searched for, just the hash. It's in principle possible to iterate through all possible names to see what hashes match, but this isn't practical for any at all unusual name, and of course most obvious names have already been registered.
  • The WHOIS protocol doesn't need to change: this looks like a valid domain name.
  • It's easy to generate the records on the server side: just run some script over your WHOIS database.
  • It's easy to enhance your WHOIS client to do the hash first, but even if you don't, command line hash programs are easy to get.
  • Note that there is some chance of name collisions

You still might need ICANN or someone like them to force the operators to do this, since it's not clearly in their interest. On the other hand, direct cost to them is so low that it's hard to really object to on difficulty grounds.

Technical Note 1: This problem is related to private information retrieval but is dramatically easier because we don't care about the server knowing what record we fetched if it exists, only if it doesn't exist. Actually, we only care if the record exists. We don't need the record itself, which makes the problem yet easier.

Technical Note 2: It would be nice to have a solution that didn't allow dictionary attack. The best solutions I know use Bloom filters.

  • The server can send you a Bloom filter with the names he knows. This is completely resistant to dictionary attack but is still of linear size in the number of inserted domain names per key. And, of course, there are false positive issues.
  • The client can request the values of specific bits in a server-side Bloom filter. By asking for a superset of the bits you want you can get some dictionary attack resistance. This has much lower space requirements, but still leaks some information to the attacker—I haven't done the math on how much, but it clearly scales to some extent with the number of bits requested, with the limit being all of them.

Note that the hash solution isn't technically constant size in the number of registered names either—the required hash size for any given false negative probability depends on the number of registered names. However, since 160 bits is so small people just think of this as constant size.

 

January 8, 2008

So, the other day I needed to register an account with Chase. Part of the registration procedure is the now ubiquitous out-of-band delivery of some token/code to your cell phone, email address, etc. (I've heard this called "loopback" or "answerback").

Here's what they offer me (somewhat reformatted and trimmed, and with my phone number redacted even further):

We'll show you all contact information we have on file for you. Some of it may be outdated, but we'll only send you an Activation Code using the method you select. Note: For security reasons, we have hidden parts of your contact information below with "xxx." Learn more about why we do this.

...

Phone Call to :
 xxx-xxx-YYYY
 xxx-xxx-WWWW
 xxx-xxx-YYYY

OR E-mail Message to: exr@rtfm.com

First, note the duplication of the phone numbers: YYYY appears twice. A minor issue, though. Note also the substitution of the numbers with xxx.

Now check out the email address: exr@rtfm.com. Note that the middle letter of my username is k, not x, and this isn't xxx either. Anyway, so I'm registering here for the first time and I look at this clearly wrong address, and I figure it's a typographical or transcription error (x looks like k, after all) and I should call get it fixed. But no.... this is just their masking technique.1 OK, so maybe I'm a moron, but seriously, how hard would it be to use * instead of x, like everyone else?

1. Mrs. Guesswork hypothesizes that their algorithm is to take the middle part of my username and so if my username were longer I would get the full xxx treatment.

 

January 1, 2008

Dave Winer is unhappy that he took his Mac to the Apple store with a broken hard drive. Apple replaced the drive but then wouldn't give it back. Winer claims they're going to refurbish it and give it to someone else and is concerned about data leakage.

I share this concern. I generally don't let others have access to my hard drive even if I expect them to give it back—for instance if they're repairing some other part of the computer. In theory, you can clean off the hard drive if it's functioning properly, so you can take a backup, wipe the drive, and then restore it when the computer comes back. But of course once the hard drive itself starts to fail, then disk wiping tools present an obvious problem, so you either need to keep possession of the hard drive, or use encryption. Encryption has the obvious advantage that you don't need to replace your own hardware, but of course it's more of a pain to use upfront and you need to worry about losing your data if you lose the encryption key (that's kind of the point, after all).

That said, I do kind of wonder whether the drive is actually going to be refurbished. Hard drive technology changes pretty fast and I wonder if it's really worth refurbishing old drives.

See also FSJ on Winer.