Receive new posts as email.
This site operates as an independent editorial operation. Advertising, sponsorships, and other non-editorial materials represent the opinions and messages of their respective origins, and not of the site operator. Part of the FM Tech advertising network.
Entire site and all contents except otherwise noted © Copyright 2001-2011 by Glenn Fleishman. Some images ©2006 Jupiterimages Corporation. All rights reserved. Please contact us for reprint rights. Linking is, of course, free and encouraged.
A Buffalo, NY, man gets an early morning visit (and alleged contusions) from the ICE: His left his Wi-Fi network open, and extremely poor FBI work (according to this AP report) led to a raid on his home because that's where the IP address led. While it's no crime in the US—it is in some other countries—to leave your network open for anyone to access, this isn't the first time this has happened. I've written up a few previous similar incidents that led to police or federal agents breaking down the doors for criminal acts conducted over the network at the physical address. In most cases, a neighbor is the guilty party.
You'd think the FBI would be briefing agents on this issue, so that they don't face multi-million-dollar lawsuits for faulty work that pinpoints the wrong person. The Buffalo man isn't suing, even though his attorney alleges he was thrown down the stairs by Immigration and Customs Enforcement (ICE). He says they didn't properly identify who they were after breaking down the door and brandishing weapons. (Who knows from ICE?)
Even on an open network, it's possible to track identifiers that would allow relatively easy confirmation of which machine was the case, or to stake out the area for a few nights, tracking signals and locations. Then agents could enlist the homeowner with the open network to ensure the Wi-Fi signal remained available and could be used to track at which exact moment that a perpetrator was engaged in an illegal act and then raided at the same time. (We're talking child pornography here, not file swapping.)
The AP article says that US-CERT recommends "closing" a Wi-Fi network among other security measures. This option, labeled differently on each maker's router software, disables default beaconing, and thus the network name and availability isn't broadcast. However, whenever the network is use by a party that knows the name and has associated with it (encryption or otherwise), traffic can be snooped and connection information extracted. I don't recommend closing a network as it provides no effective security, and neither does limiting an network to specific MAC addresses (the Wi-Fi adapter's unique hardware number).
US-CERT has six recommendations for best home practices on its Securing Wireless Networks page, which include these two. Closing a network is noted as "Protect Your SSID."
Really, using a nine-letter/digit WPA password is the simplest way to protect a network in a reliable and secure way no matter what other restrictions are in place.
I choose to password protect my network in part because I don't want to be indirectly responsible for anyone's actions on my network (whether in a raid or just because someone commits a nefarious act using my router), and because Comcast caps my use at 250 GB per month.
The Wi-Fi Alliance, mobile operators, and hardware makers have agreed on a standard for secure and greatly simplified cell-to-Wi-Fi handoffs and cross-networking roaming: The various parties have worked together to create a certifiable method of allowing handsets to access carrier Wi-Fi networks with much less fuss. The standard will also allow simple roaming across carrier networks without the current necessity of creating an account or entering account details. The whole thing is backed by WPA2 security for the Wi-Fi connection, obviating Firesheep, sidejacking, and other compromises on the wireless connection.
For carriers, this means avoiding re-inventing the wheel for every handset or platform. Carriers can buy and integrate gear from companies that have achieved this certification, and that should take them a long way towards allowing every device a carrier offers with Wi-Fi to be able to offload traffic from mobile broadband to Wi-Fi as efficiently as possible.
The Wi-Fi Alliance cites research group Informa as predicting 4.6 yottabytes (4.6 million terabytes) of data will be consumed on cellular networks in 2012 worldwide. The Wi-Fi Alliance predicts its current count of 750,000 hotspots worldwide (which must be measuring only paid and managed locations) will double by 2014. There are millions of less formal hotspots available which won't be affected by today's announcement.
One of the tidbits in the announcement, not particularly emphasized as a pair, is that certified devices will connect to appropriate networks "in many cases" using cellular credentials like SIM cards, and using WPA2 security. What that says to me in big flashing letters is WPA2 Enterprise with EAP-SIM. That's just how geeky I am about Wi-Fi.
WPA2 Enterprise is a Wi-Fi version of the 802.1X port-based access control that limits access to a network quite effectively until proper credentials are presented. In WPA2 Enterprise, only WPA2 (AES-CCMP) encryption is allowed. EAP is a simple communications language that's used by 802.1X to send messages back and forth. It's not secured by default, and must be, because the messages contain credentials. PEAP, EAP-FAST, and EAP-TLS are all popular corporate methods of securing the handshake for logging in.
EAP-SIM is one of the required methods for any approved Wi-Fi device for several years, and uses the SIM (or, I believe, similar modules on other networks) to provide the identity wrapped in a secure method.
Using EAP-SIM with WPA2 Enterprise would allow a feature phone, smartphone, or other cell-embedded device or modem to create a secure connection across the local Wi-Fi connection without a user being involved in any part of the login procedure.
The financial side of roaming across carrier networks wasn't discussed today. I confirmed with the Wi-Fi Alliance that that's a separate discussion as any kind of mobile and data roaming is today. I fear for that particular area. Cellular carriers outside of the same home country charge unjustifiably high rates for roaming: the carrier allowing a non-native customer to roam marks up its service enormously, and the roaming customer's provider adds on top of that. In the modern world, the cost is fairly tiny on the back-end to allow roaming. It's simply a high-margin profit center, and one that European Union regulators have slashed away at. Regulators in other countries lack the cross-border controls or the regulatory interest to get involved.
My fear therefore is that carriers will act like carriers do, and charge extremely high amounts of money for something that benefits from greater use rather than higher prices. Carriers should be encouraging the roaming use of Wi-Fi, a resource that's much cheaper to operate and has vastly more bandwidth in small areas than a cellular network can more expensively provide.
It will probably be more of the same, no matter how technically elegant.
This New York Times article has a major inaccuracy related to WPA/WPA2 key cracking: The article is a welcome rundown on the security issues involved in using home and hotspot Wi-Fi networks, along with changes happening at major Web sites in moving to always-encrypted sessions.
The reporter quotes a sysadmin and security videocaster pointing out that essentially all WEP-protected networks are crackable. This is true. WEP is straightforward to crack; it's just a matter of time, and often not very much time.
But the reporter misses the boat when she writes:
A WEP-encrypted password (for wired equivalent privacy) is not as strong as a WPA (or Wi-Fi protected access) password, so it’s best to use a WPA password instead. Even so, hackers can use the same free software programs to get on WPA password-protected networks as well. It just takes much longer (think weeks) and more computer expertise.
That's extremely misleading and mostly inaccurate. The distinction she fails to make, which will confuse all readers, is that there are weak and strong WPA/WPA2 passwords. I've been tracking this subject for years, as regular readers, know, and that distinction is key, if you'll pardon the pun.
If you pick a WPA key of 10 characters are more, preferably not including a word found in dictionaries of dominant Roman-character languages, you are nearly certainly protected against cracking. Pick a short phrase of 8 or fewer characters, no matter how random, and you can be cracked by a determined party, possibly in as few as minutes for a short or dictionary-word key.
WPA/WPA2 can only currently be cracked via brute force. The article should have just said more accurately, "it's best to use a WPA password instead, making sure to create one that's 10 or more characters long." Instead, it's spreading a mistaken impression.
Later in the article, sense reasserts when the writer says to change your SSID (the network name is part of how the key is derived for a WPA/WPA2 Personal), and "choos[e] a lengthy and complicated alphanumeric password." It doesn't have to be very long or very complicated. "Abra23dabra" would be a perfectly fantastic WPA/WPA2 password.
It's remarkable how a little information can span the globe so quickly: The Reuters story on 7 January about a new WPA crack overstated the case, as I remarked in "WPA Cracked? Unlikely, Despite Headlines." I tried to get some clarification from Thomas Roth, the researcher cited in the story, who will present details at an upcoming Black Hat conference. He responded to my first request confirming that it was just an enhanced brute-force attack, but not to my second, asking how many characters in a random WPA/WPA2 passphrase could his method crack in the time he cited. (Subsequent attempts to get a response haven't been answered.)
Roth did give more detail to New Scientists, however: his 20-minute Amazon.com cloud computing hosted crack broke a six-character password, which he hasn't revealed. (A short passphrase is unlikely to be random.) Roth says that he has sped up the operation since by a factor of 2.5x.
This is impressive, but shouldn't cause anyone to quiver in their boots about a "WPA crack." It's been known for some time that short WPA/WPA2 passphrases, which are converted through an algorithm into a long TKIP or AES-CCMP key, are weak, but the algorithm isn't vulnerable to a way to speed up brute forcing. Each additional character you add to a WPA passphrase dramatically increases computational difficulty.
At present, I wouldn't risk a passphrase shorter than nine characters randomly derived with a mixed of numbers, punctuation, and upper and lower case. That might hold against cracking (unless quantum computation becomes practical) for decades to come.
A German security researcher snagged some great headlines today, but I suspect the impact is modest: Reuters ran a story today about Thomas Roth's claim that he can hack into WPA-protected networks by crunching passwords in Amazon's Elastic Computing Cloud (EC2) on-demand computing service. I have a query into Roth, but haven't heard back yet. The report says he'll release software after a Black Hat conference presentation later this month. I expect he's developed an approach that uses Amazon's preconfigured instances to produce vastly faster dictionary attacks than are commonly available. (Amazon allows users to tap into the graphics process or GPU, which can offer order of magnitude improvements in certain kinds of mathematical operations, including some forms of password cracking.)
The concept isn't new. In December 2009, "Moxie Marlinspike" launched WPA Cracker, a fee-based dictionary and brute-force cracking service; see my write up at the time. Elcomsoft offers commercial desktop distributed password cracking for preshared WPA keys—along with a host of other types of passwords—with GPU support, too. I interviewed Elcomsoft's chief a few months ago for the Economist, and he provided me piles of information about how difficult it is even with his software to crack well-designed password systems.
WPA/WPA2's weakness is in passphrase choice, something that's been known for years. Researcher Robert Moskowitz gave me permission way back in 2003 to publish a paper on this issue. It remains the most popular article in every year since. Because of how the passphrase conversion routine takes the text you enter for a WPA/WPA2 Preshared Key (PSK) "password" and turns it into a long hexadecimal key, it's susceptible to cracking—but only when the starting passphrase is very short or comprised of only words found in dictionaries (along with common substitutions, like zero for the letter o). The passphrase is combined with the network name (SSID), which has allowed various groups to create large, precomputed cracks of common words (so-called rainbow tables) using default SSID names. (Moskowitz had wanted every access point to ship with a uniquely created name to increase entropy. Apple does this.)
Based on Reuters description, we may have lost a character with Roth's method. That is, a formerly secure eight-character randomly created passphrase, a mix of letters, numbers, and punctuation, may now need to be nine characters for the next several years to assure unbreakability. I'm looking forward to more news.
For Ars Technica, I penned this rundown of ways to stay safe on public Wi-Fi: Firesheep takes a techie sniffing tool and makes it mainstream, but there are plenty of other risks as well. Thus, I wrote this guide for Ars Technica on the best ways you can stay safe while using public Wi-Fi.
My main suggestion, as always, is a VPN: whether you rent a VPN connection from WiTopia.net or other such VPN hosts, have a corporate connection, or set up your own. Securing services is second-best, like encrypting email, and using methods to force SSL connections.
Doing nothing is no longer a reasonable option for public hotspot use unless you want a fair degree of certainty that anyone could easily spoof your identity.
The NewScientist asks if in-flight Wi-Fi or cell use might be banned after Yemeni-originated bombs: Wi-Fi seems unlikely to be disabled for security reasons. A compatriot would be required on board to navigate the login process with an account or credit card, or a script would have to be written to handle that. It seems rather complicated and prone to failure. Otherwise, a compatriot would need to be on board, in which case the compatriot could trigger the event.
There's one potential for danger, which is DNS tunneling. Devicescape and other authentication systems work at hotspots by sending particular DNS queries through to remote servers that respond with information in special text records that can provide login credentials and other information. DNS is proxied and often scrubbed for hotspots, however, and I suspect that Aircell figured this out in advance.
On the cell side, only a handful of planes in Europe and the Middle East are flying with picocells on board that can be used to establish a phone connection via a satellite data link. A number of elements would also need to be in place for a remote connection to be established. A timer or air-to-ground cell link would be much more reliable.
I expect that authorities will scrutinize in-flight cell and Wi-Fi service for additional weaknesses, but I doubt any ban will be put in place.
Steve Gibson suggests using WPA/WPA2 Personal encryption on hotspots to prevent Firesheep from working among users on the same network: That's an interesting idea, but only for the moment. Gibson explains the weakness to his solution in a comment below the post. I recommend at the bottom a solution involving WPA/WPA2 Enterprise that builds on Gibson's recommendation.
The shared passphrase version of WPA lets an access point and Wi-Fi adapter (the "station") negotiate what's sometimes called a session key (the pairwise transient key). You can't extract or crack that session key without watching the initial association during which secrets are sent, but which a party with the passphrase could monitor. But not so fast. You just need to force a deauthentication—currently not guarded against in 802.11 or Wi-Fi, but which will be one day—and all the stations will run through their four-way handshake again.
Someone who might run Firesheep, a point-and-click credential theft Firefox plug-in and proof of concept, is likely to not download and install Wi-Fi cracking software that would aid in this. Aircrack-ng, the gold standard, requires some technical know-how to use.
But the code is freely available and licensed under the GPL. Firesheep is also free, open-source, and available. All it would take is an interested party to combine the two into an active attack agent—perhaps called Firecracker. This would move use of the extension from potentially illegal in some jurisdictions (passive scanning may be legal, but sidejacking is probably a crime in most states and many countries), to definitely illegal in most areas (forcing deauthentication in order to obtain credentials). But it could still be a point and click operation.
Thus, a WPA/WPA2 Personal protected network would briefly afford some protection against Firesheep, it wouldn't be long lived.
The more sensible action is one I first heard discussed years ago. Enable WPA/WPA2 Enterprise (802.1X) on a network and give out the same user name and password to every user. This reduces the administrative burden of password management to zero, and allows any savvy visitor to get a higher level of protection. WPA/WPA2 Enterprise in the form of the most common method, PEAP, uses SSL/TLS to protect the handshake between station and access point, protecting the unique key assigned from even those with the same 802.1X login information.
Windows and Mac OS X have offered PEAP clients for years. Free clients for versions of Windows without it can be obtained. Linux has clients as well. There's no technical bar to set this up, just one of education. If you can't get users to employ VPNs, or they don't have access to them, 802.1X is a much simpler way to go.
The Firesheep Firefox extension is the perfect demonstration of how unsecured connections on open Wi-Fi networks can be sidejacked: Sidejacking dates back to 2007, coined by Robert Graham, who pulled together a variety of known and new vulnerabilities and packaged them into an automated session snatcher. Sidejacking describes the extraction of a session cookie from another user on the same network to hijack the live session that user has established with a Web site, such as Facebook or Twitter.
While a login to a site may be conducted via a secure session, many sites then drop you back into an unprotected connection in which a token stored as a browser cookie ensures the continuity of your actions from page to page. That token is vulnerable.
Firesheep turns sidejacking into a click-and-install demonstration with 26 built-in site profiles to snarf. I explain Firesheep, sidejacking, and how to defend against it—using notions of security I've written about on this site for years—in an article at BoingBoing.
I was sick of this story months ago, but...: It's significant when a search engine that already knows everything about us apparently unintentionally learns even more. Google earlier discovered, disclosed, and had third parties audit its collection of unencrypted data broadcast publicly over Wi-Fi while taking photos for its Street View images.
One might expect this would contain password, private information, and email, and Google said today its audits revealed that it did: "It’s clear from those inspections that while most of the data is fragmentary, in some instances entire emails and URLs were captured, as well as passwords," wrote a senior VP on the Google blog.
My reaction? If you're not using an encrypted connection to read email and you're not protecting your Wi-Fi link, then Google accidentally snagging some of your data is the least of your worries.
This is harsh, of course. The majority of users worldwide don't know how to secure their systems and data, nor should they. Operating systems developers, equipment makers, and ISPs have significantly improved basic encryption capabilities so that it's much easier and more likely a user with no special knowledge, after following setup steps, will have a secure link in place.
Take the simple matter of adding an email account to a mail client. In the olden days (say, 2007 and earlier), mail programs asked you to punch in details and connected only to servers and in methods you checked. A few systems and programs offered wizards to set up IMAP and SSL/TLS and authenticated SMTP and so forth, but ISPs were loathe to give everyone security service—too costly from an infrastructure standpoint.
That's changed. When I use nearly any program, host, or hardware to initiate some kind of connection, I am urged and sometimes hectored to use security, and often automagically taken into a secure realm. The iOS that powers the iPhone and iPad asks for email host details first, and then, invisibly, runs through a number of tests to see if it can establish one of several methods of SSL/TLS setups. If it can, it does. If not, it reverts to plain text, but also lets you modify the setup later.
Encryption is increasingly becoming the default. Google's "accident" should drive more people into figuring out how to solve their lack of security retroactively.
Excellent report on the state of Wi-Fi data collection and how it's continuing to expand: Google doesn't collect Wi-Fi from Street View (at least in some countries) following its data acquisition debacle, but Android does. And iPhones. And trucks driven by Skyhook Wireless. And other sources.
Bob McMillan at IDG News Service runs through how it works, the current efforts, and where privacy concerns lie. In general, publicly broadcast information is hard to contain, but McMillan examines the connection between collecting millions of SSID and MAC association by location and making this available in easily retrievable form, as Google does.
A newspaper reports that a strong password prevented a neighbors' entry to a Wi-Fi network: Next time, Ted Murphy should try 123456789, the third most-popular bad password.
At Ars Technica, you can read my long explanation of the group key weakness in WPA/WPA2 Enterprise-protected networks: The information I was given was originally under embargo, but the firm and unrelated researchers released essentially all the data except a video of an exploit in action and some of the mitigation information. Hence, the long Ars Technica piece.
Boiled down, I don't think anyone need worry about Hole196, which describes how an insider with an account on a WPA/WPA2 Enterprise network can send group broadcast packets spoofed to appear as if they originate from the access point for clients attached to that access point.
It's a hole, all right, but it requires so many particular circumstances to be met, that a spy or thief working for a company (or an outsider having gained credentialed access) would most likely have easier methods to get in--or would be detected by other means.
The best lesson I can take away from this hole? Make sure you're running virtual SSIDs if you have that option to separate guests, contractors, and others from employees; or to isolate different kinds of operations within your company.
Because each virtual SSID on an access point is treated nearly as a virtual AP, the group key isn't shared across the access point among different virtual SSID. The BSSID, or AP identifer, is unique for each virtual network on each AP.
AirTight Networks' researcher Md Sohail Ahmad will present a WPA2 weakness primarily a problem on 802.1X networks at DEFCON18 next week: The press release from AirTight doesn't give away too many details, but I can read the tea leaves to figure out where the problem lies. There's just enough of a hint.
The problem appears restricted to WPA Enterprise (802.1X with TKIP/AES-CCMP) in practical terms, because a malicious user must have legitimate credentials to gain access to the network to exploit the flaw. With WPA/WPA2 Personal (preshared key), everyone on the network ostensibly can sniff for other users' data.
But with the 802.1X mechanism used in WPA/WPA2 Enterprise, each user after authentication receives unique keying material that renders his or her data opaque. Or does it?
AirTight said in its press release that the problem Ahmad identified is found in the name it gave the exploit "Hole 196": that refers to the last line of page 196 of the revised IEEE 802.11-2007 specification.
I digitally flipped through my copy of the spec, and found a note at the bottom of the page in question, in a section on Robust Security Network Association (RSNA) used for the 4-way handshake for authentication dealing with the group temporal key (used to protect broadcast and multicast data). It reads:
"NOTE—Pairwise key support with TKIP or CCMP allows a receiving STA to detect MAC address spoofing and data forgery. The RSNA architecture binds the transmit and receive addresses to the pairwise key. If an attacker creates an MPDU with the spoofed TA, then the decapsulation procedure at the receiver will generate an error. GTKs do not have this property."
Reading that with the notion in mind that there's an exploit around it points strongly to a way in which a malicious client could exploit this and create spoofed broadcast or multicast packets appearing to come from the TA (transmitting address) of the access point that other clients would receive. Those spoofed packets would have the advantage of coming across the same trusted network, and could contain malicious payloads and attacks.
This could be a serious exploit for corporations, government, and academic institutions that use 802.1X, and rely on the intra-network security of having one user unable to sniff the traffic of any other user. No key cracking appears involved at all; it's entirely about the position of the offending client within the network.
It seems like the fix for this would require an AP somehow sign a GTK packet so that a station (client and adapter) wouldn't accept GTKs on a network from another station. That seems like more infrastructure and a major change, although it could be incorporated into an EAP method that relies on AP/server-side certificates.
I'm sure Cisco, Juniper, and others will be all over this, because it affects their core client base. The risk isn't from outside attack, so it's not an immediate concern that script kiddies will drive up to corporate networks to attack them. Rather, it's part of ongoing mitigation of risks from employees inside a company misusing or stealing data or causing grief.
In the short run, using a VPN tunnel within an 802.1X session might allow malicious disruption but not data interception. Unless, perhaps, DNS poisoning and SSL/TLS certificate authority spoofing were involved.
The alleged Russian covert agents uncovered in the suburbs used ridiculous communications methods: I'm flabbergasted by the techniques described in the FBI complaint about how the soi-disant spies communicated. In at least a couple of cases, the FBI states, a Russian official and one of the accused covert agents used ad hoc Wi-Fi to communicate over short ranges.
I suppose this seemed like a sensible method...to a six year old, although I wouldn't want to accuse a six year old of such simplemindedness. Perhaps spycraft for Russians hasn't caught up to, say, 1999, but needing close physical proximity is a simply bizarre requirement for passing information.
Ad hoc networking broadcasts information about the senders all over the place, which the FBI captured. The communicators clearly didn't even change the MAC address (the unique Wi-Fi adapter number) or the ad hoc BSSID.
I won't be surprised to learn that they were using WEP encryption, which the FBI broke, and lacked a layer of encryption on top of that.
Without jeopardizing national security, because I don't know anything that every attendee at DEFCON isn't better aware of than I am, I would have used one of the following methods.
Ultrawideband (UWB). While UWB hasn't caught on, there's plenty of gear out there. Indistinguishable from noise without special equipment, two relatively close devices could shift tons of information rapidly via UWB without creating overt attention.
Public Wi-Fi. Creating an ad hoc network is suspicious. Instead, the two parties communicating could log into a cafe network and use local network discovery to create an encrypted tunnel. That could be spotted, too, but it would appear potentially more innocuous.
Public Wi-Fi in freaking different locations. Explain to me again why, what with the Internet and plausibly unbreakable strong encryption, VPNs, and other obscuring tools, why spies would use close proximity to exchange data? Log in 100 miles away at separate cafes, create a tunnel between the two machines that doesn't betray origin, destination, or contents, and there would be vastly less to make a case on.
Now, I suggest these methods not to encourage spies, but because every goshdarned techie with any slight knowledge of encryption and wireless communication would think of them first.
The former Soviet spy agency is clearly not recruiting from its elite Internet hacker division for wet ops.
WEP continues to rear its ugly head: Researchers from Core Security Technologies have found a way to force Cisco Aironet 1200 Series access points to use WEP for broadcast communications if a mixed-mode WEP/WPA security model is set.
I'm not surprised. Devices in mixed mode behave in peculiar ways, and being able to force a WEP broadcast means that the entire network is susceptible to that weak method.
The only good WEP is dead WEP. Companies that have been weaning themselves off WEP need to do an audit, figure out if they have any mixed-mode networks operating, and why in god's name any piece of gear on the network has a need for WEP a this point.
WEP should be dead, but legacy gear that would be expensive to operate provides holes in retail and corporate networks. Companies should have taken the pain to upgrade, rather than face multi-million-dollar risks.
The Wi-Fi Alliance has a timetable for eliminating outdated WEP and TKIP security from certified Wi-Fi devices: A couple of news sites ran unsourced stories yesterday and today about a roadmap from the Wi-Fi Alliance for eliminating older encryption methods from the certification process for new hardware.
I picked up the phone (yes, crazy, I know!), and confirmed it: TKIP and WEP won't be allowed in new devices with the Wi-Fi stamp in a staged elimination over three years starting in 2011.
Anyone reading this site should be well aware that WEP (Wired Equivalent Privacy), the original local-link encryption standard in 802.11b, has been broken since 2001, and horribly so since 2003.
TKIP (Temporal Key Integrity Protocol) was a backwards compatible replacement introduced in 2003, and intended to work with older silicon that didn't have either the circuits or computational muster to handle WEP's real replacement, AES-CCMP (you don't want to know what that stands for, honestly). AES (also from 2003) is often called WPA2 encryption, although it's more particularly an encryption type that's part of WPA2.
While TKIP hasn't been broken, it has known vulnerabilities, such as a susceptibility to dictionary-based attacks for short keys (eight characters), and some very clever ways to insert packets through manipulating a flaw in the packet integrity protocol. (See my 2008 Ars Technica article, "Battered, but not broken: understanding the WPA crack," and my article on this site, "Another, Better TKIP Attack That's Still Limited" from Feb. 2010. It's likely more will be found.)
The 802.11n standard only allows the use of AES keys, which sometimes provokes confusing statements about its capabilities. Apple updated a support note on 3 June 2010 which stated that 802.11n with WEP or TKIP could only operate at 54 Mbps, when it's perhaps more accurate to state that 802.11n drops down to 802.11g to handle these older security types.
Kelly Davis-Felner, the Wi-Fi Alliance's marketing director, said, "We had a process within our membership to say we have a few aging security mechanisms, one of which is known to be obsolete - and that would be WEP, of course - and we wanted to define what the roadmap would look like to get the whole industry to end of life" the technology.
The Wi-Fi Alliance is a membership trade group that sets certification standards for products that bear the Wi-Fi seal. As such, its efforts are driven by what the members want, and the group allows a typically consistent approach across the entire industry.
The alliance's product manager for putting WEP and TKIP out of their misery, Sarah Morris, said that TKIP and WEP will be phased out in stages starting 1 January 2011 until 1 January 2014. Changes affect only new devices seeking certification. Companies can also release 802.11 equipment without the Wi-Fi imprimatur, although that's extremely rare, and essentially unheard of among any major equipment maker.
At the start of 2011, access points will no longer be certified with TKIP as an option by itself, commonly revealed as WPA-PSK, WPA-TKIP, or WPA Personal. Mixed modes, in which an AP can accept either TKIP or AES keys, will still be allowed.
But also starting in 2011, manufacturers can opt to ship Wi-Fi hardware preset to use WPA2 out of the box. Currently, Wi-Fi-certified access points have to be set to open, and a purchaser configures it to use security. This is an interesting change, and part of what Davis-Felner said will be greater efforts in the coming year to promote security.
In 2012, new Wi-Fi adapters (so-called stations in 802.11 parlance) won't be allowed to support TKIP.
In 2013, WEP is finally disallowed for APs. While that seems incredibly late, its inclusion is there only for certain categories of legacy devices for which no other option is available. WEP is used by point of sale systems and older hardware that can't be upgraded. It's perhaps too kind to leave it as an option for that long, but it's also a membership decision, so clearly justified by a remaining installed base.
In 2014, the mixed TKIP/AES mode for access points can no longer be included in certified devices, and WEP cannot be available to new client devices.
The move to an all-AES world is long in coming. "You've heard us say for a long, long time that WPA2 is the recommended configuration for any Wi-Fi network or enterprise," said Davis-Felner. "This is a strong expression of that position."
Without beating this story to death, I'll round up the current status: The story so far: Google sniffed open Wi-Fi networks while taking pictures for Street View, and, it says inadvertently, collected dribs and drabs of regular packets from these open networks, too.
In Hamburg, Germany, the city's data protection head (cool that the city has such an office) says Google won't turn over the data it collected for examination; Google says it's still figuring out whether under German law turning off this data to the Hamburg chief would be itself another violation of privacy.
In the same New York Times article, it's noted that Hong Kong's privacy commissioner might impose sanctions after Google ignored his request to look at data.
The Times says that Google has destroyed data collected in Denmark, Ireland, and Austria after being requested to so by those nations' regulators; eight other countries have asked for the data to be kept. Google said elsewhere that it had turned the data over to a third party for safekeeping.
Lawsuits continue to mount, too. I wrote a few days ago about a Northwest US effort to get a class-action suit going, and why I thought the suit was technical nonsense, and unlikely to pass muster on those grounds (who knows about legal). (An Oregon judge just ordered Google to hand over related data within 10 days.)
Now, Galaxy Internet Services, a veteran wireless network provider in New England, has sued in that state, trying to get class-action status. There's also a California suit underway.
I give none of this much chance of success. Regulators and privacy commissioners may impose token penalties. What if the penalties are $50m worldwide? A pittance for Google, and happily paid to resolve it. (It's more likely to be $100,000s total.)
This will raise more awareness about the dangers of open networks that are unintentionally open, and more people will enable encryption.
Google's greatest penalty will be more restrictions on its actions in all realms, however, which could extract a greater price than any fines or lawsuits.
Google adds a test of a secured search page: Google offers SSL/TLS security for its Gmail service (through a browser or client protocols). It's extended that in a trial for searching. SSL/TLS provides a (so far) unbreakable encryption tunnel between a client (such as a Web browser) and a server.
If you're using a VPN service or a VPN connection to your company when working on an open hotspot network, securing search isn't terribly important. And securing search alone isn't enough; a secured proxy Web server that lets you redirect all queries would be better.
However, for those without the resources to use a VPN (or pay for a service like Anonymizer) could turn to Google for at least a bit of protection.
And if you live under a regime in which searches are dangerous, a secured search--if not blocked--is a conduit to freed information.
Regulators and commissioners in several countries express dismay and demand information from Google: It will likely turn out that Google collected only nonsense from its passive scanning of open Wi-Fi networks, but nonsense or no, the company will face increased scrutiny all over the world as a result. It's fairly ridiculous the company didn't know it was collecting such data; it shows a lack of oversight of the code base and the results. But it will have serious political and regulatory consequences.
I won't attempt to link to every bit of news, because there's simply too much. The New York Times has a good overview in looking at the Hamburg data protection supervisor, who wants Google to turn over a hard drive containing some of the collected material. (It would be nice if the Times would get WLAN right: wireless local area network, typically called a Wi-Fi network, rather than "wireless area network," which is just wrong.)
Google hasn't yet responded to that, although it has destroyed some data (under third-party supervision) collected in the Republic of Ireland after an order from the Irish Data Protection Authority. The UK Information Commission Office has made a similar order.
Skyhook Wireless's chief, Ted Morgan, explained to Motley Fool how his firm had specifically avoided capturing any data other than simple beaconing details. He told the Fool, "when you are doing the passive sniffing you have to make sure you are not accessing private network messages. It's not a hard thing to do; you just do not record those messages."
The FTC in the US will likely open an inquiry into Google's data collection, too, the Wall Street Journal says. Canada's regulators have said they will contact counterparts in nine other countries to discuss Google's actions, USA Today says.
Google's CEO, Eric Schmidt, is trying to wave his hands to get rid of the problem. The Times Online reports that at a Google conference in England he said that "the company had not authorised the activity of its Street View cars"--another way of trying to pass the buck. You're the CEO. If the company is engaged in the activity, then you are responsible for it, regardless of which manager screwed up.