Archive for the ‘security’ Category

TKIP security is not “Gone in 60 Seconds”

Friday, August 28th, 2009

On the train home last night, I read the paper by Ohigashi and Morii that made the news yesterday, and resulted in a good number of electrons being spilled yesterday afternoon.

Before I get started, the key point here is:

If you have concerns about wireless security, JUST USE CCMP.

(CCMP is often referred to as WPA2, but that’s a nomenclature point that I’d rather not get into here.)

I enjoyed reading the paper because the attack is clever, and nicely builds on some work from a year ago by Eric Tews and Martin Beck. Both the Ohigashi/Morii paper and the Tews/Beck paper describe attacks against the TKIP integrity check. Notably, neither attack is able to recover the keys used by TKIP to encrypt frames.

The most important thing to understand about TKIP is that it was intended to be an interim measure. When design work on TKIP started in 2001, there was a two-pronged approach to developing wireless security protocols. The first prong was updating the much-maligned WEP to improve security, but that effort was circumscribed because the design that emerged was constrained by the need to be hardware-compatible with the millions of devices which had already been sold with WEP support. (In technical terms, that restricted TKIP to be based on the RC4 cipher, and prevented development of a message integrity check with significant computational requirements.)

In essence, TKIP is a set of “seat belts” that keep the most vulnerable parts of WEP from being thrown through the windshield or impaled on the steering column. (One of my favorite papers about the weaknesses in WEP is IEEE 802.11 document 11-00/0362, titled Unsafe at Any Key Length, which is where the metaphor comes from.)

I’m not terribly surprised by the increasing number of papers written about flaws in TKIP. Given the severe design constraints, TKIP was a stopgap solution intended to buy time to give wireless LAN users the breathing space to move to the eventual AES-based protocol in development. TKIP had a “design lifetime” of five years, meaning that the intent was to resist cryptanalytic attacks for that length of time. The TKIP specification had matured by 2003, so it is not a surprise that flaws began to be identified last year.

Last year, the Tews/Beck paper exposed a subtle flaw in TKIP’s integrity checking. The attack described in last year’s paper required that a network have quality of service extensions enabled. Ohigashi and Morii did away with that constraint by showing that an attacker clever enough to insinuate himself into the conversation between the network and a client device can perform a similar attack.

The technical impact of this attack is small. Tews and Beck showed that a network with WMM could be subject to attacks against the TKIP integrity check. Ohigashi and Morii have generalized that work to networks in which the attacker does not need WMM to be enabled, but the trade is that the attacker must have a situation in which the victim is outside the range of the AP without relaying. Many vendors developed workarounds a year ago which continue to provide protection against this attack.

What this perceptive paper should do is heighten the disquiet regarding continued use of TKIP. Initial papers on WEP showed flaws that were not fatal, but the accretion of cryptanalytic expertise over time resulted in a complete break of the protocol which enables attackers to swiftly recover encryption keys. TKIP has not suffered this fate yet, but it is difficult to know how far off that day is. The best advice is to start using CCMP today, and make plans to move away from TKIP.

TKIP was intended for use as a stopgap, and it was optimized for use with the existing protocol features at the time of its design. It has not been extended to protect the extended headers defined by 802.11n, which is why the Wi-Fi Alliance has defined tests to prevent the use of TKIP with its 11n certification. It will never provide protection for 802.11 management frames. (To learn more about management frame protection, see the summary video for a talk I’ve submitted to the RSA conference next year.)

The future of wireless LAN security is CCMP. Let’s bury TKIP, and move away from it before it becomes absolutely necessary.

Airport security, done right

Thursday, July 31st, 2008

I often travel with a tripod because it is absolutely necessary to capture stunning night images, like the night shot from Victoria Peak in Hong Kong. Unfortunately, tripods usually feel like they’re in a gray area as far as airport security goes. Most countries have a catch-all category where “anything that’s not on the list that the screener says is a threat to security can be stopped.”

I recently attended a Trusted Computing Group meeting in Nice, France. When I wasn’t working, the food was astounding and the photography was simply amazing. Provence is blessed with some of the best light I’ve ever seen, and colors pop like nowhere else I have visited.

Unfortunately, when it came time to leave Nice, the airport security screener decided that my tripod represented a threat to French aviation security and required that I check my bag of photographic equipment. I was surprised by this because I have visited a dozen airports in Europe in the past year, all of which have allowed my tripod in cabin luggage. I had a bit of heartburn checking my camera equipment just before the bag cut-off, knowing that I would have to fetch it at baggage claim at Heathrow (if it even arrived).

When I returned home, I wrote a letter to the Nice airport requesting clarification on whether my photographic equipment was allowed. I mailed my letter just after the July 4 holiday. For good measure, I sent a similar letter to the Nice convention and visitor’s group. One of the main draws to Provence is the scenery, and clamping down on serious photography could potentially affect tourism.

Much to my amazement, I received a letter back from the airport today:

The key paragraph of the letter is the second to last one, which reads (in the original French):

Suite à votre lettre, nous avons réuni les services compétents de l’Etat, et il a été décidé d’assouplir ces mesures. Nous allons donc demander aux agents de Sûreté de ne plus retire les trépieds d’appareil photos. Vous pourrez donc emporter votre trépied en cabine lors de votre prochain voyage à partir de l’aéroport Nice Côte d’Azur.

My rough translation of this is:

After your letter, we have met with the relevant government officials, and have decided to change our security measures. We will ask that security agents no longer stop tripods and photographic equipment. On your next trip from the Nice Côte d’Azur airport, you may take your tripod in your cabin luggage.

A few thoughts on the letter I received:

  • My response appears to be personal and is in no way a form letter. It directly addresses my comments on the security experience and the questions I asked.
  • I received a response in less than three weeks, which included the French national holiday and two trans-Atlantic mail deliveries. I don’t think I’ve ever received a response to a complaint from a government body in the U.S. in just three weeks.
  • French airport officials have changed their policies based on traveler feedback! (And a foreign traveler, no less.) I can think of at least one airport security agency that doesn’t care what travelers think.
  • I once wrote to the Transportation Security Administration because I had a question on whether my rugged internal-frame backpack would be allowed on airplanes. I began my letter with a statement to the effect of “I have a question about whether an item that is not mentioned on the TSA’s lists…” The response was to send me the same list that I had written about, and indeed, the list about which I was seeking clarification.
  • When can I go back to Nice?

Better 802.1X support for VoIP phones and “network paperclips”

Monday, July 2nd, 2007

One of the recurring annoyances with many 802.11 client devices is that they don’t support the best security protocols. Wi-Fi Protected Access (WPA) has two modes: the Personal mode based on pre-shared keys, and the 802.1X-based Enterprise mode. Well-known weaknesses in the former are not present in the stronger Enterprise mode.

One of the troubles with the lack of support for 802.1X is that it causes headaches for network administrators who are concerned about security, but need some widget to build their networks that doesn’t support 802.1X. I have often labeled many of these devices “network paperclips” because they are small, often inexpensive, and frequently, do a great deal to hold networks together. This morning, Jon Oltsik, the founding father of the OpenSEA Alliance picks up on the theme:

While the PC space is well covered, there is a new network-security frontier out there that remains barren. What about Internet Protocol phones? What about mobile devices? What about network-based appliances like printers?

Jon is getting uncomfortably (for the industry at least) close to an open secret about the Wi-Fi certification, too. There’s no requirement to support 802.1X to get Wi-Fi certification, and it’s often hard to tell from the product packaging whether the 802.1X/Enterprise methods of authentication are supported, or whether the product only supports the quicker-and-less-secure PSK/Personal methods. The Wi-Fi Alliance is working on the issue of how to reduce end-user confusion about security capabilities.

What brought all this to the front of my mind this morning is the much ballyhooed iPhone. There’s been a great deal of excitement about the dual 802.11/cellular capabilities of the device to speak VoIP, but it’s dead on arrival as far as most corporate networks are concerned. In a message to the Salsa-FWNA group this morning, Michael Griego writes about the disappointing wireless LAN security support on the iPhone:

Yes, it lacks 802.1x support out of the box, supporting only PSK security mechanisms. I was personally surprised at this and expect/ hope that this will change in one of the surely-soon-to-be-released updates since it should require only adding the supplicant software to make it work.

(Background note: Salsa-FWNA is an Internet2 group that is defining methods of federated authentication across university campuses. The group is making extensive use of 802.1X, which prevents the current iPhone from doing VoIP across campus boundaries.)

Like Michael, I also hope that Apple is working on an improved supplicant for the iPhone. If the iPhone runs MacOS X, it should be a straightforward port of the existing supplicant.

Finally, I’d like to make an offer for anybody reading this. If you have a device that needs to support 802.1X, but you’re not quite sure what to do (or just need a royalty-free code base), contact the OpenSEA Alliance and we’ll work with you on customizing the software to your device. Sufficiently interesting devices will be “self-customizing” once our developers get their hands on samples.

Getting OpenSEA off the ground

Monday, June 18th, 2007

A little more than a month ago, the OpenSEA Alliance launched. One of my first volunteer roles with the organization was to act as the volunteer “electronic tsar” responsible for many of our communications with the outside world.

Reading stories like this one from Joe Kraus about founding Excite, I can’t help thinking how lucky we were to be getting OpenSEA off the ground in 2007. Excite had to get a $10,000 hard drive that held 10 GB to demonstrate their technology. Now, $10/month hosting accounts give you access to twenty times that storage. Plus, the proliferation of open source software means that a few clicks enabled the domain registration, the content management system for our site, and electronic mailing lists. A team of three volunteers was able to put the whole communications infrastructure together in a couple of weeks of spare time while working our “regular” jobs.

At this point, one of my big personal goals is to make the organization successful enough that we can “fire” the volunteer webmaster (me).

Security for retail wireless LANs

Wednesday, June 6th, 2007

George Ou blogged an interesting survey of retail wireless LAN security in his neighborhood, and rhetorically asks the question of whether we need another gazillion dollars in damage before the industry wakes up and does something about it. The problem is that features and convenience, as always, outweigh security.

With my current company, I’ve worked with a couple of retail stores to implement wireless LANs. One of the major advantages that stores perceive is the ability to add devices whenever it’s necessary to respond to demand. One of the classic examples that always came up was the idea of a store wanting to use cash registers, connected wirelessly, during sales or the busy holiday season to add check-out capacity.

The problem? Most cash registers don’t have 802.1X supplicants, and they run a motley collection of old operating systems that may not allow easy addition of 802.1X. OS/2 was a common operating system, but there was significant presence for Windows95, Windows 2000, and even (shudder) DOS. You just don’t have good options for using the right sort of wireless LAN security protocols. Most retail companies were either unaware of the risk, or willing to take the risk given the apparent high cost of upgrading to devices that were capable of supporting WPA.

Or, from the organizational perspective, it doesn’t help that retail stores are not monolithic entities. There may (or may not) be somebody in the IT department who understands the risks of using poor wireless security protocols, but I don’t think it’s a stretch to say that such a person probably isn’t involved in the details of picking out cash registers. It’s almost certain that the stores are not demanding features like WPA2 from their cash register vendors.

(Yes, this is one of the things that could be addressed in part by the OpenSEA Alliance and the Open1X Project.)

Hotel security through annoyance

Friday, May 25th, 2007

I was in Las Vegas this past week for Interop, where I stayed at the Luxor with the other Interop Labs team members. The Luxor has a “security” system for guests which requires that you have a valid key card to use the elevators to go up to the guest rooms. The system is only marginally better than the “show a key card at the elevator bank” system that other hotels use.

You see, every key card unlocks every floor. I was on the seventh floor, but the elevator didn’t require a key from the seventh floor to enable a stop on the seventh floor. If you want to get on to any floor, just get on the elevator with somebody else and wait for them to “unlock” the elevator before you press the button for your desired floor. (If you’re lazy like me, you can also let other passengers unlock the elevator buttons before you hit the button for your floor, too.)