Network and Telecom Strategies Blog

IEEE finally ratifies the 802.11n standard

Posted by: Paul DeBeasi

Does anyone really care that the IEEE finally ratified the 802.11n wireless standard…anyone…anyone…Bueller?

The sorry fact is that the final ratification will have virtually no impact on the wireless industry. This is because what customers care about most is product interoperability. The Wi-Fi Alliance stepped into the standards void in 2007 and began certifying product interoperability based upon IEEE 802.11n draft 2.0. The fact of the matter is that the Wi-Fi Alliance did such a great job with their 802.11n certification program as to make the final IEEE standard a non-event. The evidence for my statement is that the wireless industry currently ships over 1 million Wi-Fi products PER DAY, and well over 50% of those products are based upon 802.11n!

You can relax in knowing that no driver updates (or hardware changes!) are required for compatibility with the 802.11n standard. This is because the Wi-Fi alliance announced that they would not need to make any changes to the baseline requirements of its 802.11n certification program. So, any Wi-Fi CERTIFIED products based upon 802.11n draft 2.0 are automatically certified as interoperable with products based upon the final 802.11n standard.

… I’m still waiting…Bueller?

New WPA attack - updated

Posted by: Paul DeBeasi

Introduction

Back in November of 2008 I wrote about the Wi-Fi Protected Access (WPA) attack by the German graduate students Erik Tews and Martin Beck. They discovered a limited method to crack WPA, or more specifically, to crack the TKIP component of WPA.  Their paper describes the attack and their tkiptun-ng tool carries out the attack.

Now, Japanese researchers Toshihiro Ohigashi and Masakatu Morii have taken the Tews-Beck attack one step further. Their paper describe how they can reduce the attack time from 12-15 minutes down to 1 minute and how they can eliminate the requirement that the station under attack support the IEEE 802.11e QoS mechanism.

Some articles have sensationalized this attack and have even implied that AES-CCMP could be next.

Bottom line:

• The vulnerability exposed by the Ohigashi-Morii attack is no different from the vulnerability exposed by the Tews-Beck. The Ohigashi-Morii attack essentially just speeds up the Tews-Beck attack process.  More specifically, neither the Tews-Beck nor the Ohigashi-Morii attacks discover the encryption key. Instead, they systematically decrypt an individual packet of short length (e.g., ARP packet).
• The attacker cannot decrypt all the packets on a WLAN.
• The attack only exploits TKIP, which is the older “band-aid” feature created to fix WEP (WEP used RC-4 encryption). The attack does not exploit AES-CCMP. 
• If you use certificates on both your stations and your access points (e.g., you use EAP-TLS) then your network is not vulnerable to the Ohigashi-Morii man-in-the-middle attack but your network may be vulnerable to the Tews-Beck attack. 

Recommendations:

• Use AES-CCMP encryption to protect against this attack. All certified WPA2 systems must support AES-CCMP.
• Check to see if your WPA-certified systems support AES-CCMP. If so, you should configure your WPA equipment to use AES-CCMP.
• Begin a program to phase out your older Access Points and stations that do not support AES-CCMP.

Terminology

There is some confusion over the difference between the Wi-Fi Alliance certification and the actual features supported by the vendor equipment.

WPA certification: The older Wi-Fi Alliance WPA certification designation means that the equipment was certified to support: 802.1X, EAP, TKIP, and RC4.

WPA2 certification: The newer (and now mandatory) WPA2 certification designation means that the equipment was certified to support: 802.1X, EAP, and AES-CCMP.

Vendor equipment: Some vendors chose to support both TKIP-RC4 and AES-CCMP irrespective of how the equipment was certified. It is therefore possible to configure some WPA-certified equipment to support AES-CCMP.  It is also possible to configure WPA2-certified equipment to support TKIP-RC4.

More detailed information:

   Erik Tews and Martin Beck paper

Toshihiro Ohigashi and Masakatu Morii paper

Glenn Fleishman article

Maximizing ROI for mobile applications - part 2

posted by: Paul DeBeasi

Introduction

Enterprises use many different approaches to develop applications on mobile devices. This post continues a three part series on maximizing return on investment (ROI) for mobile application development. Part 1 explained why mobile application development is so difficult and introduced three common deployment approaches. This post discusses the benefits and challenges of each approach. Finally, Part 3 will provide specific tips to help enterprises maximize mobile application ROI 

Thin client

The thin client approach uses a mobile browser to access a server resident enterprise application. This approach has the following benefits and challenges.

Benefits

• Application reuse – Many enterprises can re-use their server-based applications by simply providing mobile browser access to those applications.
• Rapid development time – A thin client application requires less development time that the other approaches because the programmer does not need to integrate with different hardware, operating systems, and software development kits.
• Portable – Enterprises can develop thin client applications that are portable across different mobile devices and browsers. One major caveat is that mobile browser compatibility varies from browser to browser (just like on a laptop). The mobile web initiative can help enterprises develop technical best practices to improve user experience on mobile devices.

Challenges

• User unfriendly – Mobile browsers are notoriously difficult to use. Try browsing the web using this opera mini simulator.
• Requires network connectivity – A thin client requires a continuously active network connection to access the application.

Thick client

The thick client approach deploys a full-featured smartphone-resident application. This approach has the following benefits and challenges.

Benefits

• Native look and feel – Programmers develop thick client applications using software development kits (SDKs) that are native to the mobile device. Therefore, the application can take advantage of the these native application programming interfaces (APIs) to achieve a device-appropriate look and feel.
• Hardware access – The developer has access to the mobile device hardware (e.g., GPS, accelerometer) via the native device APIs (e.g., Apple iPhone SDK).

• Integrated security/management – Some platforms (e.g., Windows Mobile and Blackberry) have very strong built-in security and management capabilities.

Challenges

• Limited portability – A thick client is programmed for a specific hardware/software platform (e.g., Nokia E60 and Symbian) and is therefore not easily ported to a different platform. Writing to an application platform (e.g., Java Micro Edition, .NET Framework, Binary Runtime Environment for Wireless) can improve portability but still lacks the portability of the thin client approach.
• Bigger development investment – Any enterprise that wants to support several different types of mobile phones (e.g., BlackBerry, Nokia, and Apple) and uses the thick client approach, must plan for a bigger development and support investment because each platform requires a unique development effort (See www.deviceanywhere.com for testing resources).

Mobile middleware

The mobile middleware approach uses an abstraction layer that sits between the native mobile phone hardware/software and the enterprise application. This approach has the following benefits and challenges.

Benefits

• Portable – Most mobile middleware systems support a broad range of hardware and software platforms. One of the greatest benefits of using a mobile middleware system is the ability to port applications to many environments.
• Integrated security/management – Some platforms (e.g., Sybase iAnywhere Afaria) have very strong built-in security and management capabilities.
• Integrated applications – Some platforms provide built in mobile messaging applications (e.g., email, instant messaging).

Challenges

• Lack of standardization – Mobile middleware APIs are not standardized. Therefore, an enterprise cannot easily change mobile middleware vendors.
• Cost – Unlike many thick client development platforms, mobile middleware solutions are not free.  The enterprise must pay for license fees.

Next time

This post reviewed the benefits and challenges for each approach. In part 3, we look at specific tips to maximize the return on your investment.