May 9, 2008

Notes on P2P Blocking and Evasion

In preparation for the IETF P2P Infrastructure Workshop, I've revised and expanded this post into a "position paper submission.

Introduction

In mid-2007 it was revealed [4] that Comcast was blocking peer-to-peer traffic (most famously BitTorrent) on their network by injecting RST packets to terminate TCP [7] connections. The BitTorrent community almost immediately discovered carrying BitTorrent over an encrypted tunnel (VPN or SSH) was not subject to blocking, thus completing another cycle of the ongoing arms race between peer-to-peer implementors and network operators. This paper explores some predictable next moves in the game and their consequences for the network.

This isn't intended to be comprehensive, because the request was for short papers, but I think it hits the high points. You can find the full note here.

Posted by ekr at 10:19 AM | Comments (0)

April 20, 2008

What the heck is Format Preserving Encryption?

Voltage (full disclosure: I have a number of friends there and I'm on their TAB) have released a technology they call Format-Preserving Encryption (FPE). The basic technology here is fairly old and is described in a paper by Black and Rogaway, but as far as I know, this is the first attempt to try to put it together in a single commercial package. Below I attempt to describe some of the relevant technical issues, which are sort of interesting.

Why FPE?
The use case for FPE is simple: say you have a database that contains information with multiple levels of sensitivity. So, for instance, if you're Amazon you might have a customer database that any employee can access but you'd like the credit card numbers to be accessible only to employees that really need it.

The classic approach here would be to use database access controls. This works well as long as you trust the DB server, but if, for instance, you want to send a copy of the DB to someone else, then you may not be able to trust their server, so you need to redact the database, which can be a pain. Another problem here is that sometimes sensitive information like CCNs is used for customer identification, which means you can't just redact the CCN. Rather, you need to replace it with something that's unique but doesn't leak the CCN itself. And of course, if someone compromises your database server, then all bets are off.

The problem with simple encryption
The natural alternative is to use encryption. Encrypting the whole database doesn't help, because you want users to have access to most of the database, just not to the sensitive fields. So, what you need to do is encrypt just the sensitive fields. This turns out to be trickier than it looks.

For example let's say we want to encrypt the social security number 123 45 6789 using AES-ECB. So, we might do:

This kind of sucks. Not only have we managed to start with a 9 digit string and end up with a 128-bit random-appearing value, none of the bytes of the output are ASCII digits. So, if our database or database software is expecting to have values for this field that look like SSNs, we've just broken that invariant.

The source of the problem, of course, is that we're using a block cipher in ECB mode, and most block ciphers come in a small number of sizes (64, 128, and 256 bits are the standard ones). A block cipher just randomly maps the input space onto the output space, so ECB mode encryption effectively selects a random b-bit value (where b is the block size). The smaller the fraction of the possible values that are valid, the higher the probability that the output will be invalid. To take the specific case of SSNs, there are approximately 2^{30} valid values (if we think of the trailing zeros as not counting), so the chance of producing a valid value by random chance is vanishingly small (order 2^{-98}).

One thing you might think would make sense would be to use a different mode than ECB, say counter. The problem with counter mode in this case is that you need to use a different section of keystream (or a different key) to encrypt each value to avoid easy cryptanalytic attacks. So, you need some per-value distinguisher that gets carried along with the ciphertext, which expands the amount of storage you need for the encrypted values, even as it keeps the ciphertext small.

Luby-Rackoff
As noted above, our big problem is our block size is too large. As noted above, even though SSNs are 9 digits long, they are sparsely packed (for instance letters aren't allowed), so there are approximately 2^{30} valid SSNs, as long as we use a better mapping than straight 1-1 digit correspondence. For instance, think of the 9 digit SSN as a value from 1 to 999,999,999 (not all 9-digit numbers are valid SSNs, but for simplicity, let's pretend they are.) We can represent that in binary as a 30 bit quantity. If we had a 32 bit block cipher, we could encrypt this value with less than 10% expansion, which might be OK under some circumstances (we'll describe how to do better below).

Ordinary block ciphers have blocks much larger than this, of course, but it turns out that there's a generic technique for making block ciphers of arbitrary size (actually, even values only), called Luby-Rackoff (L-R) . The nice thing about L-R is that it's a general construction based on a pseudorandom function (PRF), which we know how to build with standard cryptographic techniques.

Cycle Walking
We can use L-R to build a block cipher with a block size of any number of bits we want, but this still means that our function produces 2^b possible values where b is the block size, but this generally won't line up perfectly with the set of values we want to encipher. To return to our SSN example, we have 10^9 possible values, which means we need a block size of 30 bits, which implies a set size of 2^{30} = 1073741824. So, for any given input value, there's about a 7% chance that it will encrypt to an invalid SSN (greater than 10^9). If the database (or software) is really aggressive about validity checking, then you'll have an unacceptable rejection rate.

To deal with this issue, Black and Rogaway describe a technique they call "cycle-walking". The idea is that we start with an initially valid value (1-999,999,999) and then encrypt it. If the ciphertext is also valid, we stop and emit it. If it's invalid (greater than 999,999,999), we encrypt again, and repeat until we have a valid value. This gives us an encryption procedure that is guaranteed to produce an in-range output. Decryption is done in the same way.

Bottom Line
So, why can't we just use cycle-walking? Because it only works well if the block size is approximately right—if the size of the valid set is a lot smaller than the block size of the cipher, then you have to do a lot of iterations in order to get an in-range result. So, you can't use a 64-bit block cipher in order to encrypt an SSN because you end up having to do a prohibitive number if iterations; you need to use L-R to construct a block cipher of approximately the right size and then use cycle-walking to shave off the last few values.

UPDATE: Paul Hoffman pointed out to me privately that it's not clear how this all relates to FPE. Basically, FPE means the combination of L-R plus cycle walking. This lets you do one-to-one and onto encryption for most set sizes. If the set size is really small, there's another technique (also due to Black and Rogaway): you encrypt all possible input values and then sort the ciphertexts. You then use the index of the ciphertext in the sorted list as the encrypted value. This is obviously prohibitively expensive unless the number of possible values is small because it requires encrypting all possible values and then keeping a very large mapping table.

Posted by ekr at 9:43 AM | Comments (0)

April 12, 2008

TPMS and privacy

Schneier expresses concern about the tire pressure monitoring system (TPMS). The way TPMS works is that each wheel contains a pressure sensor and a radio transmitter which transmits pressure data to a receiver in the car, which somehow alerts you if the pressure is too low. The alleged problem is that in order to allow distinguishing wheels from each other (and from those in adjoining cars), each wheel has a unique identifier, raising the possibility that one could build a radio receiver which would listen for these transmissions and track your car.

Obviously, this isn't that attractive a feature, as Hexview observes:

What problems exactly does the TPMS introduce? If you live in the United States, chances are, you have heard about the "traffic-improving" ideas where transportation authorities looked for the possibility to track all vehicles in nearly real time in order to issue speeding tickets or impose mileage-adjusted taxes. Those ideas caused a flood of privacy debates, but fortunately, it turned out that it was not technically of financially feasible to implement such a system within the next 5-10 years, so the hype quickly died out.

Guess what? With minor limitations, TPMS can be used for the very purpose of tracking your vehicle in real time with no substantial investments! TPMS can also be used to measure the speed of your vehicle. Similarly to highway/freeway speed sensors that measure traffic speed, TPMS readers can be installed in pairs to measure how quick your vehicle goes over a predefined distance. Technically, it is even plausible to use existing speed sensors to read TPMS data!

...

As every other tracking technology, the TPMS was introduced as a safety feature "for your protection". One might wonder why NTHSA (a government agency) would care so much about a small number of accidents related to under-pressurized tires. And why would it choose to mandate TPMS and not run-flat technology? Are we being tracked already? I hope not.

It's absolutely true that NHTSA required TPMS. It doesn't look to me, however, like NHTSA required this particular implementation, or any particular implementation. They just required that the car be able to detect that the car be able to detect loss of pressure by more than 25%. As Hexview observes, there is a simple implementation that dramatically reduces the privacy problem: encrypt the sensor readings, and as far as I can tell this would be quite compatible with the NHTSA requirements (this doesn't totally reduce the problem because of radio fingerprinting, but this is harder than just reading the ID out of the air). The good news is that since there's no need for my car to be able to read your car's tire pressure, it's quite possible for manufacturers to do the right thing without any kind of new standard.

Hexview implies that NHTSA may have required TPMS in order to enable them to monitor your whereabouts, but I find that somewhat unlikely. Certainly, when I was involved with DSRC/WAVE, privacy was foremost on everyone's minds, so it would be strange of NHTSA were to deliberately attempt to violate driver privacy. That said, the manufacturers were also pretty concerned about privacy, so if they have rolled out a system that enables tracking, that's a little surprising.

Posted by ekr at 9:26 PM | Comments (3)

March 26, 2008

WoW, glider, and the difficulty of attestation

I'm not a WoW player but a bunch of my friends are, and they seem to put in a really enormous amount of hours just acquiring experience and loot. I guess this is pretty boring even by WoW standards, so it's not at all surprising that people have developed automatic WoW players. Now Blizzard is suing MDY, the creator of one such bot, MMO Glider Unsurprisingly, Blizzard doesn't like bots, since they provide a very substantial advantage to bot users over everyone else (again, I'm not a WoW player, but I think one has to concede they have a point here) and go to a lot of effort to block them.

Unfortunately for Blizzard, determining what software is running on a remote computer controlled by your adversary is known to be an incredibly difficult problem—as far as I know there is no general solution that doesn't involve some sort of trusted computing base on the remote computer (cf. TCG), 1 which of course most people don't have. That hasn't stopped Blizzard from trying, of course. They install a program called Warden on your computer which tries detect whether you're running cheat programs in parallel with WoW itself. Unsurprisingly, MDY has circumvention technology which evades Warden. So, from a technical perspective, this is a losing game for Blizzard. However, that doesn't mean that they can't win their lawsuit.

As I understand the situation, Glider isn't a WoW reimplementation, it's just a control program for WoW. So you start up WoW (or rather Glider does) and then Glider runs the various WoW operations for you. Blizzard argues that running WoW this way exceeds the EULA and so by building a tool designed to be used this way, MDY is engaged in contributory copyright infringement.

I'm not a lawyer, so I'm not going to offer an opinion on the value of this argument, but say that this holds up in court, does MDY have a technical recourse? That's a difficult problem. Since Glider depends on WoW, if they're enjoined from doing that, then life gets a lot harder. They obviously could do a WoW client implementation from scratch, but aside from that being a lot of work, it is actually incredibly easy for Blizzard to detect; they simply can have the server ask the client for a randomly chosen (by the server) section of its code. In order to emulate a real client, Glider would need to have a copy of the WoW client floating around. Would sending the requested copy to Blizzard then constitute copyright infringement as well?

1. The two contexts in which this problem is most relevant are DRM (where the content provider wants to be able to determine that the playing application will enforce its content controls) and network access control/network endpoint assessment, where the network wants to determine that an endpoint is uninfected. In neither case are there adequate solutions against an adversarial endpoint.

Posted by ekr at 10:27 PM | Comments (1)

March 13, 2008

IETF Report: routing security

The topic of routing security has started to heat up quite a bit in IETF. Historically, there have been two general types of routing security measures:

The second class of mechanisms (e.g., S-BGP) haven't really seen any significant deployment, despite the fact that there is a real threat from incorrect advertisements. (See this post about the Pakistan/YouTube outage for an example.)

The first class of mechanisms have seen modest deployments, but the protocols are fairly primitive, with insecure (or at least pre-modern) MAC function and minimal support for key management. Basically, you used a shared key between the communicating routers (a pair in the case of unicast protocols like BGP or LDP, or a group in the case of multicast/broadcast protocols like IS-IS or OSPF). All was well—or at least quiet—until 2005, when Bonica et al. published a draft which was intended to make key rollover easier for integrity protected TCP and also to update the MAC algorithms. This, coupled with some concerns about the lack of automated keying mechanisms, caused an avalanche efect of interest in revising all the routing adjacency security mechanisms.

IETF 71 had two meetings addressing this topic:

For some reason that's not entirely clear to me, I got sucked into this stuff. My materials are below:

Posted by ekr at 7:35 AM | Comments (0)

March 6, 2008

What happened in Pakistan?

There's more than one way to censor information you don't like on the Internet. At the end of February, Pakistan's Telecommunication authority decided they didn't like a specific YouTube video and issued an order requiring ISPs to block access to YouTube. The ISPs responded by advertising BGP routes to blackhole YouTube's traffic. Unfortunately, they screwed up and the routes leaked, bringing down YouTube for everyone. Danny McPherson at Arbor Networks has the story.
Either way, the net-net is that you're announcing reachability to your upstream for 208.85.153.0/24, and your upstream provider, who is obviously not validating your prefix announcements based on Regional Internet Registry (RIR) allocations or even Internet Routing Registry (IRR) objects, is conveying to the rest of the world, via the Border Gateway Protocol (BGP), that you, AS 17557 (PKTELECOM-AS-AP Pakistan Telecom), provide reachability for the Internet address space (prefix) that actually belongs to YouTube, AS 36561.

To put icing on the cake, assume that YouTube, who owns 208.65.153.0/24, as well as 208.65.152.0/24 and 208.65.154.0/23, announces a single aggregated BGP route for the four /24 prefixes, announced as 208.65.152.0/22. Now recall that routing on the Internet always prefers the most specific route, and that global BGP routing currently knows this:

  • 208.65.152.0/22 via AS 36561 (YouTube)
  • 208.65.153.0/24 via AS 17557 (Pakistan Telecom)

And you want to go to one of the YouTube IPs within the 208.65.153.0/24. Well, bad news.. YouTube is currently unavailable because all the BGP speaking routers on the Internet believe Pakistan Telecom provides the best connectivity to YouTube. The result is that you've not only taken YouTube offline within your little piece of the Internet, you've single-handedly taken YouTube completely off the Internet.

The problem here is that BGP security is a complete mess. To a first order anyone can advertise any route and they'll be believed. In other words, the Internet is horribly vulnerable to routing attacks. There's been some work in trying to prevent this sort of thing happening (whether via accidental misconfiguration or worse yet, maliciously) but none of the solutions (S-BGP, SoBGP, etc.) but none of it has gone very far, in part because many of the proposed designs are really heavyweight and in part because (or so I'm told) the database of who actually owns what prefix is in such bad shape that you can't use it as a basis for cryptographic assertions about who can advertise what.

Posted by ekr at 10:02 PM | Comments (0)

February 27, 2008

IETF 71 Reading List

C. Jennings, B. Lowekamp, E. Rescorla, J. Rosenberg, S. Baset, H. Schulzrinne, REsource LOcation And Discovery (RELOAD), draft-bryan-p2psip-reload-03.txt.

D. McGrew, E., Rescorla, Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP), draft-ietf-avt-dtls-srtp-02.txt.

J. Fischl, H. Tschofenig, E., Rescorla, Framework for Establishing an SRTP Security Context using DTLS, draft-ietf-sip-dtls-srtp-framework-01.txt.

E. Rescorla, Keying Material Extractors for Transport Layer Security (TLS), draft-ietf-tls-extractor-01.txt.

T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.2, draft-ietf-tls-rfc4346-bis-09.txt.

Posted by ekr at 9:33 PM | Comments (0)

Why would you want an identity-based signature?

One of the first rules of crypto is that if there's a crypto primitive that's possible to build, no matter how stupid, someone will eventually build it. Nothing wrong with that—that's what cryptographers are supposed to do. But just because something is possible doesn't mean it's useful. Case in point, identity-based signatures. You may have heard of Identity-Based Encryption, in which the public key and private key are derived from your identity (e.g., your email address). Anyone can compute the public key, but you need to get the private key from a key generating authority (KGA) which serves a similar role to the CA in a PKI system. The value proposition here is that you don't need a copy of someone's certificate in order to encrypt a message to them—you can compute their public key knowing only their identity (and which KGA they use). More on this here. This means that there's no need for a certificate directory, which has historically been one of the inconvenient parts of PKI.

Unsurprisingly, IBE has a signature variant, known as Identity-Based Signatures. The basic concept here is the same: the public key is derived from your identity and you get your private key from the KGA. The value proposition is the same too: anyone can verify your signature without having your certificate. The problem is that it doesn't really add much value. In a PKI system, when you send a signed message you send (Message, Signature, Certificate). In an IBS system, you sent (Message, Signature, Identity). Otherwise, the data flow is the same. Basically, IBS is just a fancy (OK, really fancy) way of compressing the signer's certificate. 1

So, why am I going on about this? Someone just suggested using IBA in the IETF SIP WG. (draft here, mailing list discussion here, starting with my review.).

1. Indeed, as Hovav Shacham pointed out to me, the difference between an ordinary PKI system and an IBS system is to some extent a matter of semantics. Think of the certificate as part of the signature and certificate verification as part of the signature verification. It's true that the signature isn't deterministic, but then plenty of signature schemes (e.g., DSA), aren't.

Posted by ekr at 9:19 PM | Comments (3)

February 20, 2008

Wikileaks shut down

Cayman bank Julius Baer Bank and Trust has convinced a federal judge to shut down DNS service for wikileaks.org.
On Friday, Judge Jeffrey S. White of Federal District Court in San Francisco granted a permanent injunction ordering Dynadot, the site's domain name registrar, to disable the Wikileaks.org domain name. The order had the effect of locking the front door to the site -- a largely ineffectual action that kept back doors to the site, and several copies of it, available to sophisticated Web users who knew where to look.

Domain registrars like Dynadot, Register.com and GoDaddy .com provide domain names -- the Web addresses users type into browsers -- to Web site operators for a monthly fee. Judge White ordered Dynadot to disable the Wikileaks.org address and "lock" it to prevent the organization from transferring the name to another registrar.

The feebleness of the action suggests that the bank, and the judge, did not understand how the domain system works, or how quickly Web communities will move to counter actions they see as hostile to free speech online.

The site itself could still be accessed at its Internet Protocol address (http://88.80.13.160/) -- the unique number that specifies a Web site's location on the Internet. Wikileaks also maintained "mirror sites," or copies usually produced to ensure against failures and this kind of legal action. Some sites were registered in Belgium (http://wikileaks.be/), Germany (http://wikileaks.de) and the Christmas Islands (http://wikileaks.cx) through domain registrars other than Dynadot, and so were not affected by the injunction.

There's also a mirror at cryptome.

For those of you who don't know how this all works, there's registries, who actually run the domain name (.org in this case) and then there are registrars, who actually deal with the customers. Any given top level domain typically has multiple registrars that service it, all of whom populate the same database, operated by the registry. So, the locking thing stops Wikileaks from transferring their domain to another registrar who would then reactivate it.

OK, so this order controls the registrar. But can Wikileaks just go to the registry and get them to move it to some other registrar, locking notwithstanding? In this case, Wikileaks is under .org, which is run by the Public Interest Registry. Operationally, the PIR is run by Afilias. Both of these are based in the US, so presumably the injunction could be expanded to include them as well. On the other hand, as the article notes, there are plenty of registries with no US connection and the only way for a US judge to take down them domains under them would be to go after ICANN, which, despite complaints about the US running the DNS seems pretty unlikely.

As you may be gathering at this point, this is all pretty pointless. It's basically impossible to censor stuff like this once it gets out. We're seeing the first level of countermeasure here, but even if by some miracle the judge managed to shut down every domain name serving the contraband material (and since the decision loop for spreading those domain names is a lot faster than your average judge's decision making process), people can just move to IP addresses published by some other means (like other people's web sites). And there are about three levels of escalation up from there, all of which are progressively harder to censor.

It will be interesting to see if JBBT goes after cryptome.org, though.

Posted by ekr at 9:42 PM | Comments (0)

February 16, 2008

Overproduction

The EFF has obtained a document under FOIA describing an incident in which an email provider which was served by an NSL for some email communications and accidentally sent far too much information to the FBI:
In late February 2006, a surge in data being collected by the FBI's Engineering Research Facility (ERF) was identified by ERF personnel. As a result ERF investigated the issue and recognized that the collection tools used to collect email communication from the subject of the investigation were improperly set and appeared to be collecting data from the entire email domain. due to an apparent miscommunication, the private internet provider accidentally collected mail from the entire domain and subsequently conveyed the email to ERF.
(NYT story here).

I'm sort of curious what kind of tools the ISPs are using here. You certainly can reconfigure your mailer to forward copies of emails to certain addresses to somewhere else, though mail going out is a little trickier. In any case, I'd be a little surprised if the FBI expected something quite so DIY. Maybe when they send you an NSL it comes with a pamphlet telling you how to reconfigure Outlook.

Apparently, this happens reasonably often. The FBI calls it "overproduction":

A report in 2006 by the Justice Department inspector general found more than 100 violations of federal wiretap law in the two prior years by the Federal Bureau of Investigation, many of them considered technical and inadvertent.

...

In the warrantless wiretapping program approved by President Bush after the Sept. 11 terrorist attacks, technical errors led officials at the National Security Agency on some occasions to monitor communications entirely within the United States -- in apparent violation of the program's protocols -- because communications problems made it difficult to tell initially whether the targets were in the country or not.

Past violations by the government have also included continuing a wiretap for days or weeks beyond what was authorized by a court, or seeking records beyond what were authorized. The 2006 case appears to be a particularly egregious example of what intelligence officials refer to as "overproduction" -- in which a telecommunications provider gives the government more data than it was ordered to provide.

The problem of overproduction is particularly common, F.B.I. officials said. In testimony before Congress in March 2007 regarding abuses of national security letters, Valerie E. Caproni, the bureau's general counsel, said that in one small sample, 10 out of 20 violations were a result of "third-party error," in which a private company "provided the F.B.I. information we did not seek."

To quote Broken Arrow, " I don't know what's scarier, losing a nuclear weapon or that it happens so often there's actually a term for it." Outstanding!

Posted by ekr at 9:19 PM | Comments (0)

February 15, 2008

I could tell you but then I'd have to kill you

Now that the House has at least temporarily refused to pass the extension of the administration's warrantless wiretapping power, there's a lot of talk about how it's destroying the security of America. For instance, here's President Bush:
"Our intelligence professionals are working day and night to keep us safe," Mr. Bush said, "and they're waiting to see whether Congress will give them the tools they need to succeed or tie their hands by failing to act."

Obviously this could be true, but we have no way to tell whether it is or not because from the beginning the Bush Administration has kept pretty much all the details about the program, including whether it's done anything useful, secret, even from Congress:

(CBS/AP) With legislation that would legalize President Bush's eavesdropping program entangled in a battle over the side issue of corporate immunity, the White House sought to move the process forward by acceding to requests from the Senate Judiciary Committee to view classified documents its members have long demanded.

However, the White House continued to draw a line between Senators and House members.

Senate Judiciary Committee Chairman Patrick Leahy, D-Vt., had demanded that other members of the panel have the same access to the same documents before he considers giving immunity to telecommunications companies that may have tapped Americans' telephones and computers without court approval. The measure is an amendment in the Senate's version of the bill rewriting the Foreign Intelligence Surveillance Act (or FISA).

White House Counsel Fred Fielding had offered to let Chairman Patrick Leahy and ranking Republican Arlen Specter see documents that might persuade them to include liability protection for telephone companies, but initially only to them.

Later Thursday, the White House agreed to expand the documents' distribution.

I'm not saying that this program isn't essential. The problem is that we have no way of knowing because the administration has deliberately denied the public the information it would need to assess what the program is and how and whether it works. We're told that that information is classified and that it's strongly implied that if we did have the information we would agree that it was important.

Again that could be true, but I remember back in the 90s when the debates over cryptography export controls were going on and we were told almost exactly the same thing, namely that wiretapping was really important and that if we just could see the classified information we would be in favor of keeping them. There was widespread skepticism about these claims on the not entirely implausible theory that the NSA might not be entirely objective about the tradeoffs between their desire to listen in on everyone's communications and people's desire to keep them private, and that just maybe it was a lot easier for them to make their case if, you know, the public didn't know anything. Anyway, when the NRC committee studying crypto policy investigated them they concluded that"

This unclassified report does not have a classified annex, nor is there a classified version of it. After receiving a number of classified briefings on material relevant to the subject of this study, the fully cleared members of the committee (13 out of the total of 16) agree that these details, while necessarily important to policy makers who need to decide tomorrow what to do in a specific case, are not particularly relevant to the larger issues of why policy has the shape and texture that it does today nor to the general outline of how technology will and policy should evolve in the future.

The basic problem here, as with the cryptography issue, is that there's a conflict of interest when the people who favor some particular policy also control the supply of information about the merits of that policy—they have a natural incentive to characterize the evidence in the way most favorable to their position. This is of course natural, but it should make you pretty suspicious when you're told that you can't have the information you would need to make an informed decision.

Posted by ekr at 10:18 PM

January 26, 2008

Skype Lawful Intercept

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.

Posted by ekr at 8:41 PM | Comments (0)

January 24, 2008

Telecom immunity is back

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.

Posted by ekr at 9:26 PM | Comments (2)

January 9, 2008

A cheap anti-frontrunning countermeasure: digested WHOIS

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:

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.

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.

Posted by ekr at 8:34 AM | Comments (5)

January 8, 2008

What the fxck?

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.

Posted by ekr at 8:21 PM | Comments (4)

January 1, 2008

Yeah, you need to watch that hard drive

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.

Posted by ekr at 8:55 PM | Comments (9)

December 23, 2007

Transitioning to universal HTTPS (2)

In my original post on Loren Weinstein's suggested adoption of universal HTTPS, I said that MITM attacks were a issue I would address in a separate post. This is that post. As cryptographers and COMSEC engineers never tire of pointing out, if your channel isn't authenticated then you're very vulnerable to active attackers. The classic attack is what's called a man-in-the-middle 1 (MITM) attack, but in general the problem is that you can end up talking to the attacker when you think you're talking to the right person. There are a lot of proposed solutions for this, but the only one that really works when you're trying to talk to someone you don't know is to have someone you do know (or at least trust) vouch for them. In TLS this is done with certificates, and the third party you trust is the certificate authority.

Whenever this topic comes up, you hear a lot of complaining about the difficulty and expense of obtaining certificates. For instance, here's Weinstein:

Certificates are required to enable TLS encryption in these environments, of course. And while the marketplace for commercial certs is far more competitive now than it was just a few years ago, the cost and hassle factors associated with their purchase and renewal are very relevant, especially for larger sites with many operational server names and systems.

It's certainly true that certs are an obstacle, though not as big an obstacle as people think. You can get a certificate for as little as $9/year. It's a little inconvenient, but it wouldn't be hard for Web hosting providers (who typically charge rather more than that) to simply issue you a certificate (or work with a CA to do so) as part of your Web site setup. But still, this is obviously more inconvenient than not doing anything. So, do you need a certificate at all? Here's Weinstein again:

However, in a vast number of applications where absolute identity confirmation is not required (particularly when commerce is not involved), self-signed certificates are quite adequate. Yes, as I alluded to in my previous blog posting, there are man-in-the-middle attack issues associated with this approach, but in the context of many routine communications I don't feel that this is as high a priority concern as is getting some level of crypto going as soon as possible.

Given their significant capabilities, why then are self-signed certs primarily employed within organizations, but comparatively rarely for servers used by the public at large, even where identity confirmation is not a major issue?

A primary reason is that most Web browsers will present a rather alarming and somewhat confusing (for the typical user) alert as part of a self-signed certificate acceptance query dialogue. This tends to scare off many people unnecessarily, and makes self-signed certificate use in public contexts significantly problematic.

Security purists may bristle at what I'm going to say next, but so be it. I believe that we should strongly consider something of a paradigm shift in the manner of browsers' handling of self-signed certificates, at the user's option.

When a browser user reaches a site with a self-signed certificate, they would be presented with a dialogue similar to that now displayed, but with additional, clear, explanatory text regarding self-signed certificates and their capabilities/limitations. The user would also be offered the opportunity to not only accept this particular cert, but also to optionally accept future self-signed certs without additional dialogues (this option could also be enabled or disabled via browser preference settings).

This topic has been debated endlessly on mailing lists, so I have no intention of detailing all the arguments. Instead, here's the bullet point version.

For

Against

This doesn't really cut in either direction, but another possibility is to reserve the https: URL scheme for real certs but to have clients auto-negotiate SSL/TLS silently where possible (like RFC 2817 but done right). This at least gives you channel confidentiality, and if you cache the fact that you negotiated SSL/TLS, then some active attack resistance.

Note that an active attacker can of course downgrade you to straight HTTP (who knows how people respond to whatever warning accompanies "hey, I just negotiated HTTP even though before I was doing HTTPS?") but, then, they could MITM self-signed certs and Weinstein's argument that they won't:

Any ISP that was caught playing MITM certificate substitution games on encrypted data streams without explicit authorization would certainly be thoroughly pilloried and, to use the vernacular, utterly screwed in the court of public opinion -- and quite possibly be guilty of a criminal offense as well. I doubt that even the potentially lucrative revenue streams that could be generated by imposing themselves into users' Web communications would be enough to entice even the most aggressive ISPs into taking such a risk. But if they did anyway, the negative impacts on their businesses, and perhaps on their officials personally as well, would be, as Darth Vader would say, "Impressive. Most impressive."

seems kinda shakey to me.

1. Amusingly, the Wikipedia entry on Interlock, a protocol designed to stop MITM, reads in part:

Most cryptographic protocols rely on the prior establishment of secret or public keys or passwords. However, the Diffie-Hellman key exchange protocol introduced the concept of two parties establishing a secure channel (that is, with at least some desirable security properties) without any such prior agreement. Unauthenticated Diffie-Hellman, as an anonymous key agreement protocol, has long been known to be subject to man in the middle attack. However, the dream of a "zipless" mutually authenticated secure channel remained.

As far as I know, this use of the term "zipless" comes from Erica Jong's novel Fear of Flying, where it refers to a somewhat different type of interaction.

Posted by ekr at 5:46 AM | Comments (3)

December 19, 2007

Hey, mind if we tap that phone?

Ryan Singel reports that despite the rather lax standards required for wiretaps, some FBI agents seem to have decided that they could skip procedure:
The revelation is the second this year showing that FBI employees bypassed court order requirements for phone records. In July, the FBI and the Justice Department Inspector General revealed the existence of a joint investigation into an FBI counter-terrorism office, after an audit found that the Communications Analysis Unit sent more than 700 fake emergency letters to phone companies seeking call records. An Inspector General spokeswoman declined to provide the status of that investigation, citing agency policy.

The June 2006 e-mail (.pdf) was buried in more than 600-pages of FBI documents obtained by the Electronic Frontier Foundation, in a Freedom of Information Act lawsuit.

The message was sent to an employee in the FBI's Operational Technology Division by a technical surveillance specialist at the FBI's Minneapolis field office -- both names were redacted from the documents. The e-mail describes widespread attempts to bypass court order requirements for cellphone data in the Minneapolis office.

Remarkably, when the technical agent began refusing to cooperate, other agents began calling telephone carriers directly, posing as the technical agent to get customer cellphone records.

Federal law prohibits phone companies from revealing customer information unless given a court order, or in the case of an emergency involving physical danger.

The actual document is here.

Posted by ekr at 8:38 PM | Comments (1)

December 14, 2007

Password disclosure and the 5th Amendment

Orin Kerr points to the decision in in re Boucher where a magistrate ruled that forcing someone to disclose their PGP password violates the Fifth Amendment. This question has been the topic of an unbelievable amount of amateur lawyering on cypherpunks and associated mailing lists and a lot of that gets repeated in the Volokh Conspiracy comments. The key question seems to be whether disclosing their password is a testimonial or non-testimonial act. I'm no expert on this topic, but as I recall, in past discussions, people have suggested having a password which is inherently self-incriminating (e.g., "I murdered John Doe") in an attempt to create a Fifth Amendment situation, which always seemed to me to be too clever by half.

Posted by ekr at 9:03 PM | Comments (4)

December 12, 2007

Transitioning to universal HTTPS

Lauren Weinstein points out that the assclowns at Rogers are prototyping a system for splicing their own messages into other people's Web pages, like this:

Lauren argues that it's time to abandon unprotected web surfing:

That first, key action is to begin phasing out, as rapidly as possible and in as many application contexts as practicable, the use of unencrypted http: Web communications, and move rapidly to the routine use of TLS/https: whenever possible.

This is of course but an initial step in a rather long path toward pervasive Internet encryption, but it would be an immensely important one.

TLS is not a total panacea by any means. In the absence of prearranged user security certificates, TLS is still vulnerable to man-in-the-middle attacks, but any entity attempting to exploit that approach would likely find themselves in significant legal difficulty in short order.

Also, while TLS/https: would normally deprive ISPs -- or other intermediaries along the communications path -- of the ability to observe or modify data traffic contents, various transactional information, such as which Web sites subscribers were visiting (or at least which IP addresses), would still be available to ISPs (in the absence of encrypted proxy systems).

Another potential issue is the additional computational cost associated with setting up and maintaining TLS communication paths, which could become significant for busy server sites. However, thanks to system speed improvements and a choice of encryption algorithms, the additional overhead, while not trivial, is likely to at least be manageable.

Weinstein raises a number of issues here, namely:

In this post, I want to address the second and third issues. MITM attacks deserve their own post. First, we need to be clear on what we're trying to do. The property the communicating parties (the client and server) want to ensure isn't that third parties can't read (the technical term here is confidentiality) the traffic going by but rather they can't modify it (the technical terms here are data origin authentication (knowing who sent the message) and message integrity (knowing that it hasn't been modified)). Obviously, there's no way to stop your ISP from sending you any data of his choice, but you can arrange to detect that and reject the data.

The general way that this is done is to have the server compute what's called a message integrity check (MIC) value over the data. The server sends the MIC, along with the data to the client. The client checks the MIC (I'm being deliberately vague about how this works) and if it isn't correct it knows that the data has been tampered with and the client discards the data. The way this works in TLS is that the client and the server do an initial handshake to exchange a symmetric key. This key is then used to key a message authentication code (MAC)1 function which is used to protect individual data records (up to 16K each).

So, going back to Issue 2, TLS actually provides confidentiality and message integrity/data origin authentication separately. In particular, there are modes which provide integrity but not confidentiality (confidentiality without integrity is only safe in some special cases so these modes aren't provided)—the so-called NULL modes. So, it's quite possible to arrange matters in such a way that intermediaries can inspect the traffic but not modify it. Of course, whether this is desirable is a separate issue, but I think it's pretty clear that many enterprises, at least, want to run various kinds of DPI engines on the traffic going by. Indeed, they want to so much that they deploy solutions to intercept encrypted traffic, so presumably they would be pretty unhappy if they couldn't see any Web traffic.

There are at least two major difficulties with providing a widely used integrity-only version of HTTPS. The first is that clients don't generally offer to negotiate it, at least in part because it's easier to just have users expect that HTTPS = the lock icon = security than to try to explain the whole thing about integrity vs. confidentiality. This brings us to the second issue, which is how we provide a UI which gives users the right understanding of what's going on. More on the UI issue in a subsequent post, but it should be clear that from a protocol perspective this can be made to work.

Moving on to the performance issue: HTTP over TLS is a lot more expensive than raw HTTP [CPD02]. So, TLS-izing everything involves taking a pretty serious performance hit. The basic issue is that each connection between the client and the server requires establishing a new cryptographic key to use with the MAC. This setup is expensive, but it's a more or less fundamental requirement of using a MAC because the same key is used to verify the MAC as to create it. So, in order to stop Alice from forging traffic to Bob from the server, Alice and Bob need to share different keys with the server. The situation can be improved to some extent by aggressive session reuse, thus amortizing the cost of the really expensive public key operations. Client-side session caching/TLS tickets can help here to some extent as well, but the bottom line is that (1) there's some per-connection cost and (2) it breaks proxy caches, which obviously puts even more load on the server.

One approach that doesn't have this performance drawback is to have the server authenticate with a digital signature. Because different keys are used to sign and verify, a single signed message can be replayed to multiple recipients. This reduces the load on the server, as well as (if the protocols are constructed correctly) working correctly with proxy caches. Obviously, this only works well when the pages the server is serving are exactly identical. If each page you're generating is different, this technique doesn't buy you much (though note that even dynamic pages tend to incorporate static components such as inline images.) Static signatures of this type were present in some of the early Web security protocols (e.g., S-HTTP) but SSL/TLS is a totally different kind of design and this sort of functionality would be complicated to retrofit into it at this point.


1. Yes, this whole MIC/MAC thing is incredibly confusing. It's even better when you're doing layer 2 communication security and MAC means the Ethernet MAC.

Posted by ekr at 7:45 PM | Comments (6)

December 3, 2007

FIPS certification pays off

OpenSSL has a FIPS-140 validated module. One of the requirements is self-testing of the PRNG. Unfortunately, it somehow doesn't quite work
A significant flaw in the PRNG implementation for the OpenSSL FIPS Object Module v1.1.1 (http://openssl.org/source/openssl-fips-1.1.1.tar.gz, FIPS 140-2 validation certificate #733, http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#733) has been reported by Geoff Lowe of Secure Computing Corporation. Due to a coding error in the FIPS self-test the auto-seeding never takes place. That means that the PRNG key and seed used correspond to the last self-test. The FIPS PRNG gets additional seed data only from date-time information, so the generated random data is far more predictable than it should be, especially for the first few calls.

This vulnerability is tracked as CVE-2007-5502.

There's no real deep lesson here. This is the kind of mistake anyone can accidentally make. It's true that the more options you have in a piece of code, the higher the chance that there will be a some code path that doesn't work right, and in this case it's particularly striking because (1) there's no need to self-test a software PRNG 1 and (2) it's the addition of the self-test that broke it, but it could have easily have been something else.

1. In general, self-testing any cryptographic PRNG is difficult. The standard way to build a CSPRNG is to take whatever your entropy source is and run it through a bunch of hash functions. The result of this is that the output looks random under standard entropy tests. This is true even if the seed is very low entropy. All a self-test really means is that the hashing part of the PRNG is working correctly, but usually it's the seeding part that goes wrong (as seen here).

Posted by ekr at 12:46 PM

November 24, 2007

OMG, you mean VoIP is tappable?

For some reason, Peter Cox's SIPtap program is getting press. First, it's immediately obvious to anyone with even minimal knowledge of networking that if you have access to the packets of a VoIP flow (or for that matter any other unencrypted network flow), you can reconstruct the data. That's why people use encryption. So, this is hardly news. That's why the IETF and others have spent a lot of time building security protocols for VoIP. Many current VoIP phones come with some encryption now and the newer stuff will be more secure and easier to deploy.

OK, so it's common knowledge. On the other hand, Cox doesn't say he discovered it, just that this is a "proof of concept". Given that it's droolingly easy to write an RTP decoder and that VoIPong and Vomit and Wireshark already existed, it's hard to see exactly what concept is being proved, other than that with enough hype you can get your name in the paper.

UPDATE: Fixed typos

Posted by ekr at 8:27 PM | Comments (1)

November 23, 2007

Combined software and services and wiretapping

For obvious reasons, law enforcement and investigative agencies aren't incredibly fond of encrypted communications. The most popular responses to this difficulty have generally been one or more of:

None of these have been particularly successful: the strong crypto cat is out of the bag, users have overwhelming rejected key escrow, and although people do sometimes have their keys subpenad (the UK has a law requiring complaince), there are standard cryptographic techniques that provide "perfect forward secrecy" so that even if your keys are disclosed after the fact your communications aren't readable. The government in the US has had some success with keyloggers, spyware, etc., but they either require physical access or compromise of the system in question.

The popularity of combined software/service operations like Hushmail and Skype opens up a new avenue, however. It's recently come out that Hushmail has in the past handed over keys to the government for users who used their online encryption system. This was made easier by Hushmails "software as a service" type architecture, where they do the encryption and decryption on their site. Hushmail also provides an option where you can download a Java applet, but it should be clear that under the right legal constraints, they could theoretically put a backdoor in the applet you downloaded, too.

Similarly, the German police have recently complained that they can't monitor Skype calls. They say they're not asking for the encryption keys, but because of Skype's architecture and the fact that Skype is involved in authenticating each call, it should be clear that Skype could mount a man-in-the-middle attack on your phone call and hand over the keys. They could also just give you an "upgraded" software version with a back door.

Combined software/service systems like Skype and Hushmail are uniquely susceptible to this kind of lawful intercept attack (or for that matter to cheating by the vendor of any kind.) If you use third party software than you don't have to worry about your ISP cheating you because they can't—they don't have the keys. And while your software vendor could potentially cheat you, they don't have the kind of constant contact with you that Skype or Hushmail does, so they would generally need to put a back door in every copy of the software, which carries a much higher risk of discovery and of users switching software. Who wants to run software with a deliberate back door?

Posted by ekr at 5:33 PM | Comments (6)

November 12, 2007

My best line of the day

Steve Burnett is giving an intro to crypto talk in which he explains that "cryptography is about turning sensitive data into gibberish in such a way that you can get the sensitive data back from the gibberish".

My observation: "This differs from standardization, where you can't get the sensitive data back from the gibberish."

Posted by ekr at 10:16 AM

November 5, 2007

Voting talk at Stanford Security Seminar

I'll be speaking tomorrow at the Stanford Security Seminar:
Some Results From the California Top To Bottom Review

Eric Rescorla

In Spring of 2007, the California Secretary of State convened a team of security researchers to review the electronic voting systems certified for use in California. We were provided with the source code for the systems as well as with access to the hardware. Serious and exploitable vulnerabilities were found in all the systems analyzed: Diebold, Hart, and Sequoia. We'll be discussing the effort as a whole, providing an overview of the issues that all the teams found, and then discussing in detail the system we studied, Hart InterCivic.

Joint work with Srinivas Inguva, Hovav Shacham, and Dan Wallach

If you want to listen, heckle, whatever, it's at 4:30

Posted by ekr at 11:36 AM | Comments (1)

October 29, 2007

Traffic blocking evasion and counter-evasion

When faced with a traffic blocking (or, as Comcast calls it, delaying) scheme like Comcast is using for BitTorrent, it's natural to ask how to evade the blocking. At a high level, there are two possible strategies:

Resilient traffic
The blocking strategy Comcast is using is to forge TCP RST packets to kill the connection. The advantage of this strategy is that it's cheap; you don't need to touch any of the routers at all. Whatever packet inspection box you're using just sources a single packet to each sender, and the ordinary TCP mechanisms shut down the connection. By contrast, if you actually wanted to stop the packets from flowing the traffic you'd need to insert transient filters into some router, which isn't necessarily that convenient, especially if we're talking about a high-speed core router.

The good news from the perspective of the communicating parties is that this leaves open a window to evade the blocking. Richard Clayton observes in the context of the Great Firewall of China that if the peer implementations simply ignore TCP RSTs then they can't be blocked via this mechanism. Unfortunately, this interferes with TCP's normal operation, since RSTs do something useful. Worse yet, there are lots of other ways to interfere with a TCP connection. For instance, the attacker could forge FIN packets, simulating a normal close. Alternately, he could send fake data segments, breaking the protocol parsing at the next level up. The bottom line here is that TCP was not designed to be DoS-resistant, especially from an on-path attacker. That's not straightforward to fix, especially by this kind of crude modification to the TCP stack.

That doesn't mean that it's not possible to make the traffic resilient to blocking. The standard approach here is to use cryptographic message integrity/data origin authentication to prevent the attacker (Comcast) from inserting their own traffic into the connection. Unfortunately, this can't be done at the appplication layer above TCP (e.g., SSL/TLS)—the attacker is attacking the TCP layer and security protocols like SSL/TLS depend on correct functioning of the lower layer protocol to function correctly. In fact, SSL/TLS makes the problem worse, since any interference with the ciphertext causes integrity failures and connection failure. (This is the same reason why SSL/TLS can't be used to fix the BGP TCP connection reset issue.)

In order to be resistant to this kind of injection, you need to have message integrity at a layer below TCP. The standard solution here is to use IPsec, but you could also use a datagram transport protocol layered over DTLS. The important thing is that the traffic has to be authenticated below the connection management state machine.

Of course, all of these schemes can be blocked if you're just willing to inject filters into the router. The good news from the attacker's perspective is that these connections are long-lived and so you don't have to inject the filters that quickly. You also don't need to get every packet—TCP uses packet loss as a congestion signal and backs off, so if you can achieve an even modest packet loss rate, you can have a dramatic impact on the performance of the connection.

Hiding Traffic
The other major strategy is to stop whatever deep packet inspection (DPI) engine the ISP is using to detect filesharing traffic. The idea here is that the ISP only wants to block some of your traffic, since they want you to be able to use your Internet connection for other applications. So, you just need to stop selective blocking.

The natural way to do this is to use encryption. Even an encryption protocol like SSL/TLS that is above TCP does a reasonable job here, since it hides the application traffic. Interestingly, BitTorrent encryption doesn't seem to help here. I don't really know any details of BitTorrent's encryption, but presumably the issue is that there are unencrypted protocol elements that are specific to BitTorrent and so the DPI box can still do some traffic analysis.

Even with a generic protocol like TLS, the attacker can still do a fair amount of traffic analysis based on timing, packet sizes, etc. You also get the TCP port. BitTorrent doesn't use a single fixed port for data connections, so the attacker can't just block that port. However, the port range is somewhat predictable and doesn't overlap with ports for other popular protocols, so if you see a lot of data flowing on one of the potential BitTorrent ports, it's a good guess that it's BitTorrent. Note that if you use IPsec, then you can hide the ports from the attacker, but the packet size, timing information, etc., is still available.

The counter-countermeasure to this kind of traffic analysis is to send deliberate "cover traffic". When you want to send real traffic you just substitute it for some of the cover traffic. Of course, to do this well you need to chew up a lot of bandwidth on the cover traffic, which is unfriendly and hard on the rest of your performance.

Summary
The bottom line here is that an attacker who controls your Internet connection can always guarantee that you can't use it. The best you can do is make it hard for the attacker from selectively blocking some of your traffic and leave the rest of it alone.

Posted by ekr at 10:53 PM | Comments (8)

October 9, 2007

So much for hiding your face

Redacting digital information turns out to be a tricky proposition, at least if you go by how often people screw it up. The usual situation is some declassified document where the government has just put easily removed black boxes over the relevant text, but in this case it's an individual who made the mistake, a certain alleged pedophile who posted incriminating pictures. of himself with his face obscured by the Photoshop twirl filter. Unfortunately for him, it turns out that this effect is reversible:
Apparently, the suspect, or whoever handled the pictures, did not think it was possible to reverse the twirling, a capability that at least one Interpol official was intent on keeping confidential.

Now the cat is out of the bag. Officials are declining to say just how they did it, leaving Interpol in the strange position of urging the public to help find one pedophile suspect while refusing to divulge a tool that might identify others before they hear today\u2019s news and rush to delete potentially incriminating twirled images of themselves.

By publishing the untwirled photos of their suspect today, the international police organization also decided to risk the possibility that the man -- or men who happen to look like him -- may face violence from vigilantes.

Apparently, this effect is really trivial to reverse. According to this BoingBoing post you can just set the twirl filter to negative and you get the original picture back. Obviously, there are transformations which would be more complicated to reverse; for instance you could encrypt the relevant pixels or randomly permute them, though any fixed transformation which is one-to-one and onto should be reversible with enough effort. In addition, there are transformations which destroy information and are partly or wholly irreversible. The obvious case is replacing the relevant pixels with pixels all of the same color. This is of course simple, but apparently not as obvious as you might think.

Now where things go wrong with a lot of redaction operations—especially with formats like PDF—is that the basic formats are more complicated than bitmaps. The redactors just create a new black object that is in front of the the text to be redacted. The underlying information is still there, so it's just a matter of removing/ignoring the black object and you have the original text. It's much safer to work with a bitmap format where you know that you're changing the relevant pixels rather than just masking them. Of course, you also need to use a transformaton that actually can't be easily reversed.

Posted by ekr at 10:47 PM | Comments (2)

September 23, 2007

How do you lock down an iPod?

Apparently the iPod SHA-1 thingamajig has been reverse engineered. As I said earlier, I'm not convinced that this actually was intended to lock down the iPod. However, it's interesting to ask how one would actually do that in a way that was harder to reverse engineer.

Two goals were ascribed to the alleged SHA-1 in the database:

If all you have is a hammer, everything looks like a nail, and if you're a COMSEC guy, problems like this bring crypto to mind. At a high level, there are two cryptographic strategies for this kind of job: encrypt the database which is then decrypted by the iPod/iTunes or apply an integrity check which is checked by the iPod/iTunes. Each of these have advantages in some contexts, but we can treat them mostly the same for the purposes of our discussion, so without loss of generality, let's talk about an integrity check.

The difficulty, as with most cryptographic contexts, is key management. We want to make sure that only legitimate copies of iTunes can produce databases that the iPod can verify, which means that iTunes has to contain a key that isn't known to third party developers. There are two options here: all copies of iTunes have the same key—this is basically the same as a fixed, secret, integrity check function or one over unknown data, i.e., the situation we have now. Any system of this type is very vulnerable to key extraction via reverse engineering. Once you have the key (or the function) you can write your own program.

The other approach is to use a separate key for each copy of iTunes. When a new iPod is attached to iTunes, it gets a copy of the key (imprinted). The most attractive mechanism here is probably to use public key cryptography and put the public key on the iPod. The key can even be signed by Apple to avoid false imprinting. Then all database updates are signed and the iPod verifies them. Of course, you can still mount a reverse engineering attack and extract the key from a single copy of iTunes, but then we're in an arms race where Apple can program new iPods to ignore that key, thus forcing the third-party software authors to constantly change keys.1

Another strategy for the attacker is not to extract a single key but rather to have the third-party software extract keys from a valid copy of iTunes, though this is obviously this is a bit inconvenient if you don't want to be involved with Apple's software at all.

If this sounds like the kind of issues you have with DRM, it is. And like DRM, the attacker has an enormous advantage as long as your system is software only and he's prepared to reverse engineer it. The situation changes a lot if you are willing to have trusted hardware (in this case on the host computer) but that would be a big change for Apple.

1. If Apple is willing to force people to register online, you can make detection and revocation of extracted keys much more efficient.

Posted by ekr at 9:17 PM

August 22, 2007

SHA-1 rumors

I'm not at CRYPTO but my sources tell me that there may have been some more progress on SHA-1 and that the latest estimates are on the order of 260.x. Anyone with more details please post them in the comments.

Posted by ekr at 6:36 AM | Comments (2)

August 6, 2007

Fail-what?

In my previous post about SWORDS robots, I referred to "fail-safe" and "fail-unsafe" strategies. Now, clearly, if you're a civilian in the line of fire of a killer robot, you'd think a strategy in which the robot shut itself down when it couldn't communicate with base to be "safe", you might feel a little differently if you were a soldier who had to go out into enemy fire because a minor communication glitch caused your robot to shut down.

As another example, take a system like Wireless Access in Vehicular Networks (WAVE), which provides for communications between vehicles and between vehicles and road-side units. WAVE can be used for safety messages, such as the Curve Speed Warning message, which allows a station at the side of the road to broadcast the maximum safe speed for a given curve. Obviously, you'd like there to be some message integrity here to prevent an attacker from broadcasting a fake speed. Now, what happens when the integrity check fails; do you ignore the message?

A decent argument could be made that either ignoring or trusting such messages was "fail-safe". Obviously, ignoring them appears safe in the sense that your vehicle reverts to what it was without the WAVE functionality, so you haven't been damaged. On the other hand, the curve speed warning is designed to help safety (that's why it's being broadcast) so ignoring it is arguably failing unsafe! I don't really have a position on what's right or wrong here, but it should be clear that the terminology is confusing.

I've heard people substitute the terms "fail-open" or "fail-closed", but those are even worse. If you're an electrical engineer, a closed circuit means current flows and an open circuit means current doesn't. On the other hand, an open firewall means that data flows but a closed one means it doesn't.

I don't know of any really good terms, unfortunately.

Posted by ekr at 8:45 PM | Comments (5)

August 5, 2007

Oh good, a kill switch

Wired reports that the DoD has taken delivery of three "special weapons observation remote reconnaissance direct action system" (SWORDS) robots. (Pretty tricky with those acronyms, guys!). Anyway, these are remote-controlled robots armed with M-249 machine guns.

Apparently these robots were uh, a bit flakey, but the manufacturers say they've got all the bugs worked out now:

The SWORDS -- modified versions of bomb-disposal robots used throughout Iraq -- were first declared ready for duty back in 2004. But concerns about safety kept the robots from being sent over the the battlefield. The machines had a tendency to spin out of control from time to time. That was an annoyance during ordnance-handling missions; no one wanted to contemplate the consequences during a firefight.

So the radio-controlled robots were retooled, for greater safety. In the past, weak signals would keep the robots from getting orders for as much as eight seconds -- a significant lag during combat. Now, the SWORDS won't act on a command, unless it's received right away. A three-part arming process -- with both physical and electronic safeties -- is required before firing. Most importantly, the machines now come with kill switches, in case there's any odd behavior. "So now we can kill the unit if it goes crazy," Zecca says.

OK, so ignoring the wisdom of starting from a platform which used to "spin out of control", I'm sort of interested in how the "kill switch" works. As far as I know, there are two basic ways to build a system like this:

It should be pretty clear that if what you think there's a high likelihood that the robot's going to go nuts and you want to minimize the chance that it kills your own people, random civilians, their pets, etc., you probably want something that fails safe. This is especially true in view of the implication in this article that signal strength isn't always what you might like. You really don't want to have a situation where the robot is busy slaughtering innocent bystanders and you can't shut it down because your control unit is showing zero bars.

On the other hand, a fail-safe system is also much easier to DoS—it's probably more important when the system being DoSed is shooting your enemies than when it's serving up copies of Girls Gone Wild. All the attacker has to do is somehow jam your signal (and remember that since you probably want to have a cryptographically secured control channel, they only need to introduce enough errors to make the integrity checks fail). This makes the problem of designing the control channel a lot more difficult. I'd definitely be interested in hearing more about the design of the protocol for these gizmos.

Posted by ekr at 10:32 AM | Comments (4)

August 3, 2007

What I did on my summer vacation

For the past couple months I've been spending most of my time working on California's Top-to-Bottom Review of electronic voting systems certified for use in California.

The overall project was performed under the auspices of UC and led by Matt Bishop (UC Davis) and David Wagner (UC Berkeley), who did a great job of negotiating a wide variety of organizational obstacles to get the project going and keep it on track.

This project reviewed the systems of three manufacturers:

Each company makes both an optical scanner for paper ballots and a computerized direct recording electronic (DRE) (these are often called touchscreen, but the Hart system actually uses a clickwheel), as well as a back-end election management system.

Each system was assigned to three teams:

There was also an accessibility team for all the systems.

I led the Hart source code team, consisting of me, Srinivas Inguva, Hovav Shacham, and Dan Wallach, and sited at an undisclosed location which can now be disclosed as SRI International in Menlo Park. Our report was just published yesterday, just ahead of the statutory deadline for the State to decide on whether these systems will continue to be certifed (more detail here). You can get it here and all the reports here.

I wasn't planning on saying much about this on EG. Most of what I have to say is already said better in our report. I did want to say a word about my team, who put in extraordinary amounts of effort under an extremely tight timeline; just over a month from the time we got the Hart source to the delivery of the final report. Thanks, guys, and I look forward to working with you again, hopefully next time in a room with 24x7 air conditioning.

Posted by ekr at 9:00 AM | Comments (1)

June 13, 2007

More on collisions and APOP

Paul Hoffman asks (in comments):
Is this really easier than a dictionary attack after one unsuccessful attempt? I guess that this attack works when the APOP password is not in any attack dictionary or algorithm, but I would still like to see a comparison between the work effort for the attack and a very deep dictionary run. Note that the dictionary attack is *much* less likely to raise suspicions since there is only one failure, not many.

So, the first thing you need to realize is that this is a byte-by-byte attack. For simplicity, ignore dictionary attacks and assume that you have a 64-bit password. Searching that entire space takes, you got it, 264 operations (all offline). Now, say you mount the Leurent-Sasaki attack on only the last byte. This requires intercepting average 256 (worst case 512) connections and finding a collision for each of those connections. It seems to be a little hard to map the cost of finding a collision directly onto hash operations, but Luerent reports about 5 seconds per collision, so we're probably looking at order 100,000 (216) operations per collision, so this is something like (216) operations. But look what's happened here: we now know the last byte of the password, so we can mount a search on the remaining bytes. Searching the remaining bytes requires only 256 operations, compared to which 224 is negligible. So, we've reduced our computational complexity by around a factor of 256, admittedly at the cost of intercepting a lot more connections.

If we could extend this technique to the whole password we'd need to intercept about 8*256 connections and do about 8*227== 232 hash computations, so we'd have reduced the work factor by about a factor of two. However, as I mentioned in the original post, this technique can only be used to extract the last three bytes of the password. To make a long story short, Leurent estimates that with 8 character passwords with 6 bits of entropy per password this brings the work factor down to 230, a reduction of 218. This is obviously a big improvement.

Of course, this improvement depends on a fairly unrealistic assumption about the entropy of the password. In general, the lower the entropy, the more attractive dictionary search looks, and with typical passwords, it probably is better, especially when you factor in the negative effects of interfering with the user's connections.

UPDATE: Roy Arends points out that I apparently can't multiply and that 8*24==227. So, no breakeven point, like I'd previously suggested. I guess 8:00 PM must be past my bedtime. Fixed.

Posted by ekr at 8:08 PM | Comments (1)

June 11, 2007

A practical use of collisions

So, I'd been going around saying that the collision attacks against MD5 and SHA-1 were pretty useless against real protocols. At ECRYPT, Dan Bernstein pointed out to me that someone has actually used a collision attack successfully against APOP, an old challenge-response style protocol. The paper, by Leurent, is here (and rediscovered by Sasaki here).

The way that APOP works (like pretty much all challenge-response protocols) is that the server sends the client some challenge (a fresh value) M and the client sends back F(K,M) where K is the shared key and F is some function. In modern systems, people tend to like HMAC for F but APOP was designed before HMAC and in an era where people were pretty loose about hash functions. APOP computes the response as: MD5(M || K). This turns out to enable an attack, provided that the attacker can control the challenge.

The basic attack allows the attacker to determine one character of the password. Say he thinks the last character is C The attacker generates two colliding messages M1 and M2 with a special structure.

So, we have:

Where X and Y are arbitrary and come out of the collision finding algorithm (actually, these are longer, but nobody wants to see 63 xs.).

The attack then requires the user to authenticate twice. The first time the attacker gives the challenge xxxxxxxxxx. This causes the user to return H(xxxxxxxxxx || P1 || P2 || P3 || ... Pn) where P1 is the first character of his password, P2 is the second, etc. The second time the attacker sends yyyyyyyyyy and gets back H(yyyyyyyyyy || P1 || P2 || P3 || ...). Now, here's the key point: these challenges have been specifically arranged so that the first byte (P1) of the password lines up with the last byte of the first hash block. If P1 == C then the two first hash blocks will collide. And since P2 ... Pn are the same, the entire hash output will collide. In other words, if the attacker has guessed C correctly, then the responses to these two different challenges will be the same. Otherwise they will not be (with high probability).

We've now extracted the first character of the password. That's not bad, but what about the rest? Well, it's straightforward to extend this once we know the first character. We build two new messages:

And we can repeat the same procedure extracting the password one character at a time.

This attack strategy has been known for quite some time and is originally due to Preneel and van Oorschot. However, the bottleneck was always that finding collisions was too expensive. The discovery of efficient paths for finding collisions changes that. If it's easy to find collisions, then this method becomes very practical.

Of course, "easy" is where things get complicated. There are two factors to consider here. The first is that it can be difficult to control the collision values, so you don't always get to choose that the last n characters of the colliding blocks are equal. Indeed, Leurent reports that he can only recover the first three bytes of the password. The second complication (and this applies only to APOP) is that in APOP challenges are RFC-compliant message ids, and the colliding blocks above most likely contain non-ASCII characters and so don't fit. Implementations which check for compliance are probably not vulnerable. However, Leurent reports that he's successfully mounted this attack on a variety of clients and it works, which isn't too surprising. Note that improved collision-finding techniques could lead to relaxation of both of these constraints.

The bottom line here is that if you're using APOP without TLS you should probably stop. On the other hand, if you're using APOP without some kind of encryption you should have stopped long ago...

Posted by ekr at 7:20 AM | Comments (2)

May 28, 2007

Notes on the ECRYPT Hash Function Workshop

A few impressions from the EFHW, but first some tutorial material.

For those of you who don't know how hash functions are constructed, the basic idea is iteration. The current hash functions all use a construction called Merkle-Damgard (MD). You start with some compression function F which takes a block M of size m and turns it into a block S of size s where m > s. For SHA-1, these are 512 bits and 160 bits respectively. F also takes as input a state variable of length m. This allows you to chain by taking the output value and feeding into F as the next state.

So, the idea here is that we start with state IS and then compute S0 = F(IS,M[0]). That's the first block. We compute the second block as S1 = F(S0, M[1]) and so on. Once we've processed every block, the final S value is our hash output. [Yes, I know this only works on even block-length messages. There's a padding technique to fix this.] There are other ways to connect up compression functions but given that all the compression functions anyone is seriously proposing can only process block sizes of limited length, pretty much all the hash functions need some chaining mode, whether it's M-D or something else.

So, in order to define a new hash function you need to specify:

As I said earlier, all the major hash functions (MD5, SHA-1, SHA-256, ...) use M-D, but they differ in the compression function. Why use M-D? It's simple and you can prove that if the compression function is collision resistant than so is the final hash construction. Of course, as we've seen with MD5 and SHA-1, if the compression function isn't collision resistant, than the game changes.

So, with that in mind, the workshop:

d

Posted by ekr at 9:45 PM | Comments (2)

May 24, 2007

ECRYPT slides

If you're not already in Barcelona, it's probably too late to catch my ECRYPT IT, "Indigestion: Assessing the impact of known and future hash function attacks". The slides, however, are here.

Posted by ekr at 3:28 AM

May 20, 2007

Steelcape and Firewall Traversing VPNs

A while back, I received a spam with the following contents:
Send data without opening your ports.

Steelcape has taken an innovative approach to security, instead of trying to repair TCP/IP, we have built a solution inside the TCP/IP protocol. This method allows Steelcape to secure environments without opening ports on the firewall.

The packets are encrypted at 256 bits and signed with a 48 bit digital signature. Also works with IPv6. Please take a look at our website www.steelcape.com

This rang in at about 10W40 on my snake-oil-ometer, but seeing as they'd been kind enough to give me their information, I figured I'd check it out and if it was snake oil, make fun of them publicly.

First, you can check out their Web site, which reiterates their basic claims:

This doesn't really tell you how the thing works, though. Points 2-4 are easily understood, but what does point 1 mean? Not opening any ports? It's not TCP/IP? How does the data get through? Figuring that out required reading their somewhat confusing WP (link omitted because you don't want to give them your name and email address any more than I do), an exchange of emails, and finally a con call with one of the sales/marketing guys and some technical guys.

Making sense of this requires some background on how Enterprise networks, firewalls, and VPNs work. Figure 1 shows the world's simplest firewalled Enterprise network.


Figure 1: A basic firewall configuration

You've got a bunch of hosts on an internal network separated from the Internet via a firewall, which also doubles as the Internet access router. The firewall prevents all connections to the internal hosts from the Internet. Defining what an internal connection is turns out to be a bit tricky, so, let's just talk about TCP here. Your classic firewall forbids incoming TCP connections but allows outgoing ones, at least to some ports. This works fine if you only want to have client machines, but if you want to have servers (e.g., a Web server), you need to do something else. To a first order, you can either punch a hole in your firewall or put the mail server outside your firewall. Actually, people often do both; they run two firewalls, with the web server in between them in what's called the DMZ. The outside firewall has a hole punched in it to allow access to the Web server, but because it's outside the inner firewall there's no need to punch a hole there. Figure 2 shows what I'm talking about.


Figure 2: Firewall with DMZ

This DMZ strategy of course works less well if you want to allow VPN access to your network, since the whole point of a VPN is to allow remote—albeit secured;access to the internal network. Either you make the firewall and VPN access router one and the same or you place the VPN access router inside the firewall, i.e.,


Figure 3: Firewall with VPN router

And, of course you need to have a hole in the firewall in order to let packets to/from the VPN router.

So, this gives us the background for understanding the "no holes in the firewall" claim. The first thing you need to understand is that this is a VPN-only solution: you can't use it to secure access to your public mail server or Web server. Those need to have open firewall ports. So, the idea is that you install Steelcape's stuff on both sides of the system, for instance as an appliance on your home network and then on the laptops of your remote users.

But I've just said that the VPN server needs to be able to talk directly to the Internet. So, how does Steelcape work? There WP says:

In TCP/IP, data is sent though ports, over a network, to a firewall or other network device, and sent on to listening hosts within a businesses infrastructure. This a potential point of exposure, since unwanted packets could end up on host systems. Steelcape leaves hostile data behind at the firewall as enabled by a "pull" architecture. Steelcape-enabled hosts pull packets from the firewall, validate them, and route them on to host systems. If Steelcape does not qualify the packets, they are kept at arm's length from the system and dropped at the firewall. This is accomplished without any sacrifice network bandwidth.

This description sounds initially coherent, but doesn't make sense in light of the claim (in e-mail) that it works with commodity firewalls, which don't have any such buffering or pull built into them. You can't really get this out of the WP, but it turns out that what's going on is that you have a topology like that shown in Figure 4.


Figure 4: Basic Steelcape installation

Whereas your classic VPN installation requires one box at each site, the Steelcape design requires two, one inside and one outside the firewall. The way that this works is that the gateway has a permanent connection tied up to the enterprise server (ES). This connection traverses the firewall. When a remote user wants to VPN in, he contacts the ES and authenticates. The ES sends a message to the gateway over this permanent signalling channel telling the ES that a client wants to come in and the client's IP address. The gateway then uses NAT/firewall hole-punching techniques (like ICE but the Steelcape guys say it's not ICE) to let the remote agent talk to the VPN server (it helps here that Steelcape pushes their traffic over UDP). If this strategy sounds familiar to you, it should. It's exactly the topology used by VoIP systems, with the SIP proxy taking the place of the ES.2 It should also now be clear why this can't work with generic Internet services: they're not set up to contact Steelcape's ES.

This approach has two claimed advantages: security and ease of installation (the other claimed advantages of Steelcape's stuff come from different techniques). In terms of security, it doesn't require that the VPN server be accessible from arbitrary Internet hosts all the time. Holes only get punched for hosts which have been authorized by the ES. Think of this as decreasing the surface area of attack. Of course, the flip side of this is that the ES does have to be accessible from any host. However, it's true that in order to attack the internal network you do need to compromise two hosts instead of one, so if implemented properly this could give you a measure of defense in depth. I'm not really confident it's that enormous, but all other things being equal (i.e., Steelcape's software being equally secure to other people's software), it probably does give you a measure of defense in depth.

In terms of ease of installation, it's certainly true that you should be able to install a Steelcape system without the cooperation of the firewall administrator. This is of course the kind of feature that users love and firewall administrators hate, because (from their perspective) it's far too often used to bypass enterprise security policies.1. Certainly, I would think that most enterprises would want any VPN appliances to have the approval of the firewall admin, so getting him to punch a hole hardly seems that onerous. And on the downside, of course, now you have two machines to maintain, which increases your maintenance effort.

The other major claim, increased performance, derives from Steelcape's use of a proprietary protocol which is allegedly faster than TCP. It was a little hard to work out what the optimizations were, but it sounded like principally it was that they didn't use compression and maybe that they had more aggressive congestion control3 It's certainly the case that you can get improved network performance via link-layer compression, so that sounds plausible, though hardly proprietary. That can of course be done within standard TCP/IP (see IPComp) so there's not likely to be anything proprietary there. And of course as soon as you are doing TCP/IP translation on Steelcape's boxes rather than TCP end-to-end there's lots of opportunity for things to go wrong. So, the "replaces TCP/IP" stuff looks mostly like marketing special sauce to me.

The other thing that probably should make you seriously nervous here is that Steelcape isn't using a standard security protocol (e.g., IPsec, SSL/TLS) but rather something they designe