COMSEC: May 2007 Archives


May 28, 2007

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:

  • The compression function.
  • The chaining mode.

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:

  • Everybody wants to have a hash function that's provably secure. Unfortunately, it's not something we actually know how to do. We actually have a pretty good idea how to prove stuff about the chaining modes but the problem is the compression function. To a first order, the compression functions fall into two categories: bit-shuffling algorithms like all the current hash functions (and like block ciphers, incidentally) and algebraic functions like VSH. We know how to prove the security of the algebraic functions (or at least nobody is willing to propose one they can't prove security for) but the performance is too slow and as far as I can tell nobody has any practical ideas for how to make it much faster. Nobody knows how to prove anything about the bit shuffling algorithms.
  • The security model for hash functions is turning out to be a lot harder to define than people would like. In particular, the properties aren't limited to the classic preimage resistance and collision resistance. People would also like it to act "like" a random oracle. Why? Because the proofs of security of other constructions (E.g., OAEP, PSS) depend on random oracles. Note that current hashes definitely aren't random oracles because given a hash value H and the fact that it corresponds to some message M we can compute the hash of M || X without knowing M (this is called extension and is a basic property of the simple M-D construction). This isn't allowed of a random oracle.
  • To make matters worse, hash functions are used in a whole bunch of ways that we don't even have analyzed security models for. We have no idea what kind of properties those functions demand, so it's pretty hard to know what properties the hash function has to have not to break them. It seems likely that a new hash in the style of the ones we have now would be ok—or at least not obviously bad—but that narrows the design space a lot.
  • Not only do we not have a good theory of how to build a provable hash function, we don't really have a good theory of how to break them. We just have a bunch of techniques which people are still improving. Nobody seemed to feel confident that they could design a bit shuffling hash function that would resist a concerted attack. There's a fair amount of skepticism about SHA-256, too, mostly on the principle that it was designed before these new attacks and that it was designed by the same organization which produced SHA-0 (since badly broken) and SHA-1 (significantly weakened).
  • NIST is planning to have a competition to define what I think John Kelsey called the Advanced Hash Standard (AHS) [which as Hovav Shacham points out would presumably be pronounced "ass"]. Slides not on the Web yet, unfortunately. Summary: They don't really have any idea how many entries they're going to get, how they're going to prune them down, or what the final design criteria are going to be. There seems to be a real chance that they're going to end up with a bunch of functions none of which they know how to break but without any good way to decide between them. SHA-256 will not be part of the competition. This actually seems to me to be not that great an idea, since it's going to be kind of weird if the new functions aren't measurably better than SHA-256 but NIST is telling us to replace it, especially since by the time a decision is reached we'll have just gotten SHA-256 wedged into everything. I joked to John Kelsey that I was going to submit SHA-256 myself, along with all the papers devoted to attacking it as my submission.

May 24, 2007

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.

May 20, 2007

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

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:

  • Steelcape has the only solution that does not require the opening of ports on your firewall.
  • Our technology is up to 30% to 40% faster than TCP/IP based technologies.
  • Fast installation and minimal administration.
  • Cross platform compatible.

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 designed themselves. I didn't drill down on this too far, but apparently it uses Blowfish (a fine algorithm, but generally not a sign of crypto sophistication; the pros use AES) with (according to their product overview) a "48 bit digital signature") which is "randomized every few milliseconds". Since the security of a VPN system fundamentally depends on the crypto in use, using an unevaluated protocol isn't exactly confidence inspiring.

It should be obvious here that it's possible to design a standards-based system that uses the same firewall/NAT traversal techniques used by Steelcape. That would have some advantages and disadvantages vis-a-vis ordinary VPN approaches, plus you'd have a high level of confidence that the security protocol was secure. It doesn't look to me like that's what Steelcape is providing, however.

1. See also draft-saito-mmusic-sdp-ike-00 for a very similar standards-based approach.
2. It's interesting to note that in this case there's no requirement that the ES actually be in the DMZ. It could be some entirely different third party server on the network—after all, this is how SIP works—which puts a somewhat different spin on the above security argument.
3. They also told me that they eliminate the TCP checksum computation so that this sped up intermediate routers. As far as I know, checksum computatations are not a significant part of packet processing overhead.

UPDATE: Ed Felten hypothesizes that the 48-bit "digital signature" is actually a MAC. Another possibility is that it's not data dependent at all; it's just a secret value that gets appended to the packet. That would be consistent with the "randomized every few milliseconds" claim, since a MAC would be different for every packet. Needless to say, if that's what it is, it's not adequate.


May 13, 2007

Bellovin writes:
Those who remember the Crypto Wars of the 1990s will recall all of the claims about "we won't be able to wiretap because of encryption". In that regard, this portion of the latest DoJ wiretap report is interesting:
Public Law 106-197 amended 18 U.S.C. 2519(2)(b) to require that reporting should reflect the number of wiretap applications granted for which encryption was encountered and whether such encryption prevented law enforcement officials from obtaining the plain text of communications intercepted pursuant to the court orders. In 2006, no instances were reported of encryption encountered during any federal or state wiretap.

The situation may be different for national security wiretaps, but of course that's where compliance with any US anti-crypto laws are least likely. There was no mention of national security or terrorism-related wiretaps in the report, possibly because they've all been done with FISA warrants.

This is interesting data, but consider if you will the contrary interpretation: encrypted telephony has seen practically no deployment. During the crypto wars it was widely believed that if the government just got out of the way encryption would become ubiquitous. But export controls were loosened in 1999 and that still obviously hasn't happened. The one exception, of course, is that mobile communications are often encrypted for transmission over the air interface, but (1) they're not end-to-end encrypted so you can wiretap at the junction with the PSTN and (2) the algorithms have historically been quite weak. So, all this really does is impede wiretapping by RF collection, which is an issue for intelligence agencies but not really for law enforcement, which can just serve a warrant on the mobile provider. So, who won the crypto wars again?


May 1, 2007

As I've mentioned previously, simple password systems suffer from a variety of capture and replay attacks. All the best solutions involve cryptographic authentication but this involves changing both client and server, which is a pain (the client is the real problem). One of the early approaches to this problem was to give the users physical cryptographic tokens which they could use to generate a supplemental password. This had the big advantage that it could be deployed without changing the user's client software.

The most succesful of these tokens was the SecurID card (now part of RSA). A SecurID is a card with an LCD display that generates a new "random" value every 30 seconds. The server side is synchronized to the token and so can verify the token value. I mention this because VeriSign is introducing a credit card with a similar technology, aimed at login for e-banking.

Rosch explained that, at this point anyway, the cards would not be geared toward online retailers, like Instead, they're aiming the concept at businesses and consumers who set up online accounts, like banks, brokerages and PayPal.

The cards would hold an algorithm that could generate the six-digit passwords, which are only good for 30 seconds.

When a consumer wanted to log onto her online banking account, for instance, she would log on with her user name and password, as usual. Then the site would ask for her secondary password. She would press a button on her credit card and the numerical password would flash up on the LCD screen. The next time, she needed to log into her account, her card would give her a different number, which the site would match up with the card's unique serial number, which corresponds to the algorithm it uses.


Rosch added that even if a key logger planted surreptitiously on the user's computer picked up that second password, a hacker wouldn't be able to use it because subsequent transactions would require a different password.

This certainly seems reasonable as a phishing countermeasure. Web login and telnet are similar in a number of respects—in particular in the desire to avoid touching the client. It shouldn't be too hard to train users to type in the password from the LCD, given that it's going to appear more or less next to the credit card number. My main concerns would be the cost and durability of the cards. Durability is especially an issue. I have no particular information about durability of the ICT cards, but a card with electronics and an LCD, plus a magstripe seems likely to fail more often than just a magstripe. Even if the cards can be made as cheap as mag stripe cards, if they break a lot that means a lot of calls to customer service to get new cards, and customer service calls are expensive.

I note that they don't seem to be targeting this towards online retailers. That's not surprising since getting that right seems a lot harder. Online retail is a substantially less close fit for the password login model. In particular, merchants want to be able to both batch transactions and retain the credit card numbers for future transactions (think Amazon one-click). Obviously either of these is inconsistent with at least naive implementations of very short-term authenticators. This isn't to say it's not possible to make something along these lines work for credit cards, just that it's more complicated.