I discovered earlier today, while trying to load my personal X.509/SSL certificates onto my trusty Nokia E61i, that its personal-certificate support is for all intents and purposes intentionally broken.

When the user certificate is imported to Nokia Eseries devices, e.g to be used for authentication with WLAN connections, the certificate contents are checked and if there’s any issues with the certificate fields, the importing of the certificate will fail and the error message “Private key corrupted” is shown.

One common situation where this problem may occur is if the KeyUsage field in the certificate has the nonRepudiation bit enabled. A certificate with nonRepudiation bit is rejected by E60, E61, E61i, E65 and E70 devices because of the security reasons.

The workaround is to create a new user certificate where the nonRepudation bit is removed. The nonRepudiation bit is not necessary when doing a certificate based authentication e.g. in WLAN environments.

Yes, broken. I don’t care what the Nokia engineers were thinking when they put that “feature” in, it sucks. It basically stops you from using 99.9% of all certificates in the world — ones produced using the default settings from most issuers, and forces you to generate a brand new certificate for the device. That is totally unacceptable. Certificates cost money in many cases, and even if they don’t, they take time to create. Plus, managing multiple per-device (rather than per-user) certificates is a royal pain in the ass.

Nokia’s “solution” to the problem would force me to generate a brand-new certificate for my mobile, and then I’d need to replace the certificates stored on every other device with the new one, in order to make sure I can decrypt S/MIME email. If I didn’t do this — if I used one certificate on the E61 and another on my desktop and laptop, the E61 wouldn’t be able to open encrypted email sent in response to messages originating from the other machines.

(This is all assuming the E61i can even do S/MIME, which I’m not 100% sure of; but since it can’t load my certificate, it’s a bit of a moot point.)

Hardcore failure on Nokia’s part. Security, no matter how well-meaning, is worse than useless if it breaks functionality or makes the user’s life this difficult. All it does is raise the ‘cost’ of security, and make it more tempting to forgo things like certificate-based authentication at all.

Up until recently I’ve been pretty happy with the E61i, but I’m feeling more and more that they just didn’t take core functionality seriously enough. The software is flaky and unreliable, as is the Bluetooth stack (I get lockups about once a week when I’m using it with a BT headset or tethered to a laptop), and I question whether anyone who worked on the built-in email client actually used it. (When you have an entire QWERTY keyboard to work with, why does every action require at least 3 clicks on a miniature D-pad?) It does have its charms — JoikuSpot is amazingly useful, and I love not being locked into an iPhone-style “App Store” — but the warm fuzzies are really wearing off.

It’s starting to become clear to me why BlackBerry, and not Nokia, is so dominant among users who actually care about communication over everything else. (BlackBerry offers both S/MIME and PGP, although it seems like it may need to be deployed to an Enterprise Server rather than to individual handhelds.) It’s just unfortunate that the BlackBerry offloads so much intelligence to the BES/BIS backend; I’m not really comfortable being that tied-in to somebody else’s infrastructure, and I don’t really feel like running my own BES.

Maybe it’s time to take a look at Palm.

According to a post on the Full Disclosure mailing list, history has repeated itself: T-Mobile’s systems have apparently suffered a serious breach, and a lot of customer data has been compromised. Oops.

The last time something like this happened to T-Mobile, it was due to a known vulnerability in BEA’s WebLogic application server that T-Mobile had failed to patch correctly. Although the ‘hacker’ in question ended up in the Federal pen for his trouble (one hopes the celebrity email-reading was worth it), and a lot of attention seems to have been paid to the Secret Service’s identification and capture of him, the real culpability was T-Mobile’s. By failing to patch their servers, they left them wide open to infiltration.

It’s a bit too soon to tell whether the latest break-in was similarly due to technical incompetence at T-Mobile, or if they fell victim to some other method. However, it doesn’t sound like the ‘cybercriminals’ behind it all are the sharpest pieces of cutlery in the drawer. Unless they’re playing an amazingly deep game, I think it’s safe to say they didn’t think their cunning plan all the way through.

From the FD post:

We already contacted with [T-Mobile’s] competitors and they didn’t show interest in buying their data -probably because the mails got to the wrong people- so now we are offering them for the highest bidder.

Sounds almost petulant, doesn’t it? “Probably because the mails got to the wrong people” — really? They seriously think that’s the problem? If only they’d had the contact information for the Espionage Division of AT&T, the whole thing would have gone so smoothly!

They would have done better to read up on the Coke / Pepsi trade-secrets bust from back in 2006. A disgruntled Coke employee stole the secret Coke formula and tried to sell it to Pepsi, but Pepsi — much to her surprise, I’m sure — pretty much fell over itself notifying Coke of the offer, and then worked with the Feds during the ensuing investigation. Although the press coverage tried to make a heart-warming after school special out of the whole thing, Pepsi’s behavior should have been predictable and obvious: the risk of getting caught with stolen trade secrets from their fiercest competitor so greatly outweighed the value of those secrets, there was no way they would ever take the thief up on her offer.

The very same situation now exists for the morons who stole the data from T-Mobile. What competitor would even think of touching it? What could any competitor possibly gain from the data that would be greater than the huge downside risk, and could not be obtained more easily some other way? I can’t think of anything. Even if the files were totally complete, and represented dossiers on every one of T-Mobile’s customers completely documenting their behavior and preferences with regards to cellular telephony, it still wouldn’t be worth the near-certain chance of getting busted down the road, when T-Mobile notices a startlingly high number of their subscribers getting poached.

The smartest thing for AT&T, Verizon, Sprint, et al to do, on receiving an offer to purchase obviously stolen records, would have been to immediately report it to the Feds. That they didn’t makes me guess that they probably didn’t even take the offer seriously. How humiliating!

After failing to sell the goods (which I suspect are database dumps) to T-Mobile’s competitors, the thief or thieves then decided to just post a for-sale ad to the Full Disclosure mailinglist — well known in IT security circles, but not known as a clearinghouse for stolen identities. It’s not as though there aren’t venues on the ‘net where trading and selling identity information is common — supposedly there are whole online communities for this purpose — but the FD list certainly isn’t one of them. The only way they could have been more bush league is if they’d used Craigslist. Or maybe Ebay.

So that brings me to two possible conclusions about the whole breach:

1. It was conducted by someone of questionable technical competence (at this point it’s too early to tell), but dreadful business skills, who couldn’t resist undermining the commercial value of the information they stole in order to claim credit in a high-profile way. They chose the FD list rather than some more appropriate sales channel because the FD list gets read by a fair number of security experts, and this means more geek cred. Of course, what ‘geek cred’ gets you in prison is beyond me. (Maybe Hans Reiser knows.)

2. It was conducted by someone who knows exactly what they’re doing, and what we’re seeing is a carefully-constructed ruse of some sort. There might not be any information to sell, or else selling the information at a maximum profit might not be the real goal. Instead, the purpose would be to embarass and tarnish T-Mobile’s reputation as badly as possible.

Admittedly, option #2 does get a little tinfoil-hatty. To profit from it, someone would need to build up a huge short position in DT stock (or certain futures contracts), and hope that the news of the breach would cause the value to slide. However, I don’t even know if this would be realistic: DT is a huge company, and T-Mobile USA is only a part of it. Even a cataclysmic security breach might not do more than wiggle the needle of DT’s share price, requiring a huge position or lots of leverage to take advantage of it.

Neither theory bodes well for the people behind it; according to option #1 they’re clearly incompetent and far beyond their depth as far as professional criminality is concerned. Not exactly a hard target for law enforcement. According to option #2 they’re less stupid, but still at a huge disadvantage: the position they’d need to have built up to profit from the security breach would be visible in retrospect, possibly even obvious. Even spread between lots of accounts, I suspect it wouldn’t take long for the forensic accountants to catch on.

It will be interesting to see how everything pans out in the next few weeks. There is no scenario where it looks good for T-Mobile; those who, like me, are T-Mobile customers can only hope that this time they’ll learn the lesson a bit better, and put some more effort into security.

This is just a quick breakdown, as far as I’ve been able to determine, of which models will allow you to access the ‘net through them, and which are too braindead/broken/Windows-centric. (This is not necessarily an exhaustive list, and is not guaranteed to be correct! Be sure to do your own research before purchasing or signing a contract.)

Options to consider:

• BlackBerry 8800 (GSM)

Reported to work; source is Tom Yager of Enterprise Mac. The discussion forum on Fibble.org also has some instructions. This seems to be the starting point for most of the 88xx variants.

• BlackBerry 8820 (GSM and WiFi)

Reported to work by BlackBerryForums member “CatherineLW”, via Bluetooth only.

• BlackBerry 8830 (CDMA and Euro-GSM)

Reported to work via Bluetooth, not via USB. Follow-up article here. It’s also described as working (in “exactly 2 minutes”) in this article.

• BlackBerry 8300 “Curve” (GSM)

Reported to work. Page includes links to required modem script and information on init strings. In the comments there are intermittent problems reported, so it’s apparently not a foolproof solution.

All information seems to relate to Bluetooth tethering; there’s no mention of success (and lots of failures) trying to tether via USB. Apparently USB tethering is, for some reason, only possible from Windows.

• BlackBerry 8320 (GSM and WiFi)

The 8320 is a special version of the 8300 made for T-Mobile; it includes some additional features including 802.11a/b/g UMA calling.

There are some scattered reports indicating that it works, and some others saying that it doesn’t. It seems like it ought to work; problems may relate to bad software revisions.

• BlackBerry 8100 “Pearl”

Reported as working by Dave Taylor of AskDaveTaylor.com, and Grant Goodale of Fibble.org.

However there are serious issues with particular software revisions. Software version 4.2.1.107 in particular, which was pushed out to T-Mobile phones, is known to have issues.

Options to avoid:

• BlackBerry 8700

For some reason, normal Bluetooth DUN methods don’t work with the 8700 series, which is unfortunate because it’s relatively inexpensive and in all other respects a nice phone (particularly the ‘G’ revision).

There’s a whole saga of efforts, including a substantial ‘bounty’, put towards getting this thing working as a USB or Bluetooth-tethered connection, but there doesn’t seem to be a very satisfactory solution. The closest anyone seems to have gotten is a $50 software package called “Pulse” which allows tethering via a proxy server that you must run (or pay for the use of), through which all traffic flows. Although I appreciate the effort involved, this doesn’t strike me as particularly elegant — frankly it’s unacceptable that it’s even necessary. Anything that requires that much of a workaround to use is broken.

The bottom line:

It’s not really much of a surprise that RIM doesn’t seem to focus very heavily on anything except Windows, given their established userbase in the corporate market, but it’s still a bit disappointing. The best BB device for Mac users at the current time seems to be one of the 8800 series, either the 8800 itself (currently retailing for $280) or the 8820/30 variants depending on whether you want GSM or CDMA service within the US. Either the Curve or the Pearl would seem to be a close second; I only give the 8800 an edge because it’s newer, and will probably be getting more attention for longer than either of the older models.

A while back I wrote up a little ‘mini-HOWTO’ on connecting to the Internet via a T-Mobile cellphone from a Mac running OS 10.4. (It’s been a while since I’ve tried it, but I think all the information is still current.)

For a bunch of reasons that are well outside the scope of this blog, I had reason recently to try and do the same thing from a Windows PC. Although I’m sure the process makes sense to somebody, I didn’t find it particularly intuitive. Just in case there’s someone else out there trying to do the same thing and struggling, I thought I’d provide pointers to the online resources I found most helpful.

This page from the HowardForums Wiki was one of the most useful and concise. In fact, it seems to be by far the most referenced document on the topic.

Most of the problems I ran into were related to my Bluetooth adapter. Unlike in OS X or Linux, where Bluetooth is handled by an OS component, Windows delegates it to a driver provided by the manufacturer. Like virtually all software produced by hardware manufacturers (scanner software, anyone?), I’ve yet to see one that wasn’t a flaky pile of crap. It’s what you get when you’re viewed as a ‘cost center’, I guess. Once you’ve gotten the phone and computer to pair, you’re about 50% done.

The HowardForums instructions tell you to configure the Bluetooth WAN connection by going into the ‘Network Settings’ control panel; on my system (Dell Inspiron 9400 with onboard Broadcom adapter) this was not correct. The network connection for the Bluetooth device connected using a ‘device’ called a “Bluetooth LAN Access Server Driver”. To configure it, I had to go through the My Bluetooth Places folder, and configure the “BluetoothConnection” in the Bluetooth Properties window. It was in that window (“BluetoothConnection Properties”) rather than in the Network Connections panel, where I could enter the ‘phone number’ used for WAN access.

With that done, the next step is to add the correct initialization string for the APN you want to use. This is all pretty much as the HowardForums article directs. If you are on the low-cost “TZones” plan, you’ll need to use ‘wap.voicestream.com’ as the APN, making the init string at+cgdcont=1,"IP","wap.voicestream.com". You’ll only be able to connect via an HTTP proxy, but it’s six bucks a month (and probably a TOS violation) — what do you expect?

In theory, with the phone number and init string entered, the Network Connection created, and the phone successfully paired to the computer, you’d be good to go. However when I tried to connect, I just got a repeated “Error 692: There was a hardware failure in the modem” error. The ‘Error 692’ problem is apparently not uncommon, and has various solutions that seem to work for different people, with no discernible rhyme or reason. In my case, the problem was due to a leading space that had crept into the init string when I copied it from HowardForums. When that was corrected, I was able to bring the connection up.

It’s so slow that really I’d only consider using it either in an emergency or times of unbelievable boredom, though it does work after a fashion. However, the same procedure allegedly works for EDGE just as well as GPRS, so when I eventually get that EDGE-compatible phone (and get the real data plan), I’ll hopefully be all set.

As reported by a large segment of the Technorati crowd, Walter Mossberg recently wrote a nice piece on the current state of the U.S. cellphone market, and why it, for lack of a better word, sucks so much. The key is all in the subsidized phone racket.

[The] whole cellphone subsidy game is an archaic remnant of the days when mobile phones were costly novelties. Today, subsidies are a trap for consumers. If subsidies were removed, along with the restrictions that flow from them, the market would quickly produce cheap phones, just as it has produced cheap, unsubsidized versions of every other digital product, from $399 computers to $79 iPods.

I think he’s the first mainstream journalist that I’ve read who has really gotten this. Phone locking, enforced mutual incompatibilities, application restrictions — the entire culture of control — all springs from subsidies. If people just bought their phones outright, they’d probably be significantly cheaper (not to mention more full-featured), there would be a greater secondary market (meaning less waste), and they’d be more prone to shop for networks based on price, service, and quality.

Perhaps as it becomes more obvious that the iPhone is, despite being (in Mossberg’s words) “the best-designed handheld computer ever made,” a costly white elephant because of carrier-mandated restrictions, there will be greater national conversation about the state of cellular telephony.

As Mossberg points out, we’ve been through this with landline phones before, prior to the disassembly of AT&T as the national monopoly carrier. It took almost a century for consumers to get first comfortable with the technology, and then impatient with the restrictions placed upon it: I don’t think cellular will take that long.

A little while ago I finally succeeded in getting mobile internet working through my phone, my Mac, and a USB cable. Although not exactly something that deserves to be in the software configuration hall of fame, the end result — internet on my laptop, via my cellphone’s GPRS connection — has a fairly good ‘wow’ factor. However, it’s not the sort of thing most non-technical people are going to be able to set up easily.

And so, with that audience in mind, I wrote up my experiences in the form of a “mini-HOWTO”. It’s a quick explanation of how to get one particular hardware configuration working, step by step. Since the hardware I’m using isn’t that uncommon (a bog-standard Motorola V3 “Razr” phone, with service though T-Mobile, a Mac laptop running the currently-latest version of the OS, and a mini-USB cable), I hope maybe it’ll be of use to somebody else, somewhere on the internets.

Permanent link here. I tossed it up there as GFDL, so if anyone would like to redistribute it, or use it as the basis for a more general HOWTO, feel free.