There is a new specification for mobile phone security called the Mobile Security Specification. It is essentially trusted computing for cell phones.

The specification has been years in development, said Janne Uusilehto, head of Nokia product security and the chairman of the working group developing this technology. "It is a big deal. This is the first time that we have created such common security specifications for all handheld devices," Uusilehto said.

More:

When these devices appear, they will make things more difficult for data thieves and mobile virus writers. Down the line, the technology could be used to build electronic wallets into mobile phones. In general terms, the specification calls on hardware vendors to store protected information in a secure area of the phones. Similar to the Trusted Platform Module used in PCs, this technology could be used to ensure that the phone's operating system, applications and data have not been tampered with.

All the usual trusted computing warnings apply here, but perhaps more so as cell carriers maintain a 'walled garden' and can limit the devices available. They are also essentially 'tri-opolies'. It seems likely that you will be able to buy a computer without TCP in the future. You might not be able to buy a cell phone without it (that works on a carrier).

That being said, it might not be a big deal, if you can have a VOIP mobile phone running on a WiMax network...

The Washington Post has an article about garage door openers not working around Quantico due to a denial of service attack by the Marines and consumers wanting to get money from the Marines.

Bad news: you don't have any rights to the spectrum and they warned 'you' in 2005. Since the military is reclaiming the spectrum to facilitate better first responder communications, they are entirely justified. If you want to get money from someone, look to the manufacturer - although unless you keep a neat garage, you might have trouble finding the warranty. And if you do, I bet you won't like what it says.

BusinessWeek points out the struggles at Palm, how their operating system is 5 years old, the last Treo was released in 2003 and they've canceled the Foleo. They announced a new Treo for Europe, which looks interesting.

We've been developing two-factor authentication clients for a long, long time. We had a Blackberry token for the 95x series of Mobitex pagers. We have software tokens for Palm, PocketPC, Blackberry and J2ME so we have dealt with a lot of devices, operating systems and carriers. Based on that, here are my recommendations for Palm:

• Maintain and leverage your software and developer base. One of Palm's main strengths was the number of apps that would run on it. This is a weakness for the Blackberry, as their developer program is not that strong - and the company clearly doesn't care about it. They think it's all about the email.
• It is all about the email. And it would not be hard to do better than Blackberry's. You can't even sort by sender, or view only unread messages. It does need to be there instantly - or seem to at least. I see they claim "Automatic delivery of Hotmail/MSN, Yahoo!, and Gmail, email as it arrives" for the new Treo.
• Make better hardware. I always felt that Palms were flimsy. I think the Blackberrys are getting a bit soft too. I'm tough on things I guess.
• Get a position in the OS market place. Lots of players will have Windows-based systems. Get a Linux-based phone. What about being the open source player? Developers love to do wireless stuff. Could be a great way to get better software, user feedback, community, etc. Don't even get me started on the BREW platform.
• Solve the 'walled garden' issues that the carriers have. Carriers are part of the problem too. If Palm can create a solution for carriers like Apple did for music labels that allows software development to flourish, that would be truly awesome.

Just a quick announcement about our new software token clients for Windows Smartphone and Windows Mobile 6 Professional. Please give them a test!

Securology has a post about RSA's software tokens. In it, two key issues with are raised, one is specific to tokens that use symmetric encryption such as the RSA software tokens:

Distributing the seed record requires a confidential channel to ensure that it is not perfectly duplicated in transit. Distributing seed records to many of the supported platforms of soft token vendors involves plaintext transmission, such as sending the seed record as an email attachment to a Blackberry client. An administrator may provision the seed record encrypted using an initial passphrase that is distributed out-of-band, but it is common practice for seed records and initial passphrases to be distributed side-by-side. Whereas a physical token can only be in one place at a time, a soft token could be perfectly duplicated by an eavesdropper, even complete with its initial passphrase (especially when it isn't distributed out of band). If Alice receives her soft token and changes its passphrase, Eve could keep her perfect copy with the intial passphrase or choose to change the passphrase-- either way, the back end of the one-time-password authentication system will receive a valid token code (time value encrypted with the seed record).

Note that this is not an issue with WiKID's software tokens as we use public key encryption. The private key remains on the device and only the public key is transmitted. It is the out-of-band method of verifying the user's registration code that matters for WiKID. This could be done over the phone or via an application which uses some existing trusted information or credentials. (We protect against a man-in-the-middle attack in this process by hashing the registration code with the WiKID server's public key before presenting it to the user. Thus, if someone is trying to impersonate the server, the registration with the real server will fail.)

The second issue is a more general concern with software tokens:

Likewise, a soft token employed on a malware-ridden remote PC could have its stored contents uploaded to an adversary's server, capturing the seed record. If the malware also captures keystrokes (as software keystroke logging is so common these days), then another opportunity for a perfect duplicate exists.

Malware is huge and growing problem. No doubt about that. It is also increasingly sophisticated and most malware today is typically not a single use piece of software, rather it is a suite of tools. For this reason, if malware is on the PC, once the PC is on your network, it is likely that a trojan horse is on your network too, no matter the authentication method. My inclination here would to invest the savings from going with a less expensive two-facto authentication system in a defense-in-depth strategy against malware that includes gateway scanning and validating updated anti-virus databases before a user is granted access to the network.

There is another risk here - which seems to go unmentioned too frequently - network-based man-in-the-middle attacks. There are a few reasons why these should be of more concern:

• The increased usage of SSL-based VPNs which use easily-ignored browser certifcates.
• The increased usage of WiFi, often in public settings.
• The increased instances and sophistication of DNS-Cache attacks

Granted, most DNS-Cache attacks are currently targeting online banking, but that will evolve as with all attacks. I bring this up, because the WiKID PC-based tokens also perform https mutual authentication. If an HTTPS url is associated with a domain, the WiKID software token will fetch the certificate at that URL, hash it and compare the hash to the one downloaded from the WiKID server with the one-time password. If the hashes match, the token will launch the default browser to URL. (This process is similar to SSH key verification.).

So, if you are using corporate laptops for mobile users and feel confident in your anti-malware solutions, but suspect (well, how can you know that they won't?) that your users will be connecting to your SSL-based VPN or extranet from WiFi hotspots, you are better off from a security perspective deploying software tokens that include mutual authentication than using hardware tokens.

The core problem is that you are relying on the security of the carriers for the security of your system. Once you cede that control, you are at their mercy. And their idea of security might not be the same as yours. Consider this recent post at Consumerist about how easy it is to hijack a Sprint Account:

Remember, all I knew about this guy was his cellphone number, that he was in his 20's, and that he lived in DC. That's it. That's all it took to completely hijack his entire Sprint account.

There are implications beyond Sprint. Any system that uses credit bureau information is potentially susceptible. Security people knew this because, after all, credit bureaus sell this information, but the implementation makes it much, much worse:

In the comments on this post, a former Sprint rep says it's even worse than we thought. They say that every question about cars has three luxury models and one typical one. He says that "none of the above" for "which properties have you owned" was correct 99% of the time. And worst of all, you only need to answer two of the questions correctly to gain access to an account. I was shocked at the number of times I was able to access an account by simply guessing the answers," he writes. "Fortunately I am an ethical person, but if I wasn't I could've done a LOT of damage very easily."

Companies make security decisions based on acceptable rates of false positives versus false negatives. The bigger the user base, the lower the tolerance for false negatvies. A cell phone company with 10 million subscribers will have a very low tolerance for false negatives. Do you want the same tolerance for your two-factor authentication? It seems highly unlikely.

More on SMS authentication issues