At the WWDC yesterday Apple announced the upcoming availability of their iPhone 3G S. In addition to a host of speed optimizations and new OS features Apple announced some new security features for the 3G S models: “Hardware Encryption” and remote wipe.

Ostensibly, the plan is that if your phone were lost or stolen you could issue a remote wipe and be confident that your data couldn’t be accessed. This is a feature that security conscious companies expect based on their experiences with BlackBerry’s “Erase Data and Disable Handheld” feature.

It’s interesting, however, to take a close look at careful wording Apple has used in their communications about the feature:

“iPhone 3G S offers highly secure hardware encryption that enables instantaneous remote wipe. You can even encrypt your iTunes backups.”

It almost sounds like the “whole device” encryption is primarily used to drive the remote wipe feature, not as an active security measure in its own right. If the encryption were used behind the scenes to secure the data on flash, then the remote wipe operation may not delete data. It could just remove the key and the device would “instantaneously” be rendered inoperable.

If that is the approach used there are some potential security implications:

• If the encryption is fully in hardware, is it really securing the device while running, or is it just enabling remote wipe? Will a strong passphrase (> 4 digits) be required to unlock the key? It’s not likely if background operations and software are running.
• Next up – the remote wipe trigger. It stands to reason that the device would need cell or network connectivity to initiate a remote wipe. Could you effectively disable remote wipe on an unlocked device by putting it into airplane mode and shutting off networking? What happens if you pop out and replace the SIM card?
• Finally, there is the matter of the encrypted backups. The statement that you can even encrypt your iTunes backups implies that the feature is optional and that backups wouldn’t normally be encrypted. This may in turn imply that iPhone application data is unencrypted when read off the device during a backup and re-encrypted for storage by iTunes. This lends credence to the idea that the scope of the encryption is limited.

This is all wild speculation of course, since very few substantive details have been released. While there is no doubt that the encryption features will enhance iPhone device security, it remains to be seen how the practical improvements will compare to the launch hype. I strongly suspect that highly sensitive information storage will still require dedicated security applications.

Stephen and I were just interviewed by Dan Grigsby for this week’s Mobile Orchard podcast. The subject of the interview was SQLCipher, an SQLite extension that provides transparent page-level encryption for application databases. We talked mostly about how SQLCipher works, Strip (our iPhone security app built with SQLCipher), the iPhone build process, and DOC cryptography classification. We even managed to crack some NSA conspiracy theory jokes!

I realized afterward that we didn’t spend any time talking about why we like to work with cryptography and what drives us to do it. I suppose there are quite a few different motivations for us, but being that last week saw June 4th, the 20th anniversary of the Tienanmen Square Massacre, I found myself looking up Tank Man again. Mostly I was thinking about the legacy of his action and that iconic photograph, but I was reminded of why we value cryptography in software.

I have a number of friends who were in China during the recent Olympics for various reasons. One was there to document things that foreign media were forbidden to cover – like the many protests that were squashed outside the stadium. My buddy @noneck found himself in some “interesting” situations. He was eventually picked up by the authorities who went through his personal items, used his credit cards and forged his signature to deport him back to the U.S. You bet they went through his iPhone looking for potentially incriminating data.

Other friends were there to work with the Free Tibet movement, and they had iPhones, too. If they’d been picked up, and their phones contained incriminating information, notes, audio, contacts, etc, it could have severely compromised their freedom and safety, not to mention their particular mission. Obviously, these are chances that Noel and the others were all knowingly taking, but I’m glad they all made it home safe.

When they came back and told me their stories, I was struck by a thought. Smart phones present amazing capabilities, like video recorders and audio recorders, that can enable people to act as journalists and/or mobile broadcasters. Information is power but sometimes it is dangerous. Even having an audio interview on your phone could get you in a lot of trouble if you’re detained by people with an axe to grind.

Unfortunately the access code on an iPhone, like the on-screen locks of most mobile devices, is not a strong barrier to accessing data stored on the device. More and more of us are taking personal photos, videos, writing notes, storing valuable contact and business information, and utilizing applications to which we grant access to our online identities and social networks.

I want to create mobile software that treats this confidential data securely. That’s why we’ve been developing a suite of applications aimed at people who need to keep secrets. Strip, our password manager and data vault, can store all types of security credentials, financial and contact information. Codebook will soon fill the real need for a dedicated secure notes application, and will add some features that we feel are missing in the Apple Notes. We have a secure audio recorder under development, too.

More importantly, SQLCipher makes it possible for other iPhone applications to provide this kind of security without adding significant complexity. It’s open source and on on GitHub so we hope to see it used in other applications some day. The Mobile Orchard interview provides some details about how it works, and how we hooked into SQLite to provide the encryption. We’ll also be publishing a tutorial shortly describing how to set up the Xcode build process step-by-step.

If you’re going to Apple’s WWDC next week, and you find yourself looking to start a new app, we hope you’ll take a look at SQLCipher. Get in touch with us if you have any questions! We’re also eager to collaborate on development, especially with porting to other platforms (some folks have already show interest in Android, CoreData, etc).

I have enough trouble keeping my amp, guitar and pedals working without an issue on stage as-is, why on Earth would I want to involve my phone in that chain of potential failure between pick-up and and input jack?

As seen on Macrumorslive.com:

11:37 am Final demo — Line6 and Planet Waves. Together they are working on a solution to control your guitar and amp from your iPhone.

11:39 am More demo technical difficulties — trying to show how easy it is to switch between settings on an amp and guitar.

11:41 am Can adjust guitar tuning without actually physically changing anything — nothing can be demoed however, as the hardware accessory isn’t communicating with the iPhone.

That looks like fail to me.

For anyone else out there who has code or services integrated with Twitter, you should take a look at this soon.

The Twitpocalypse is similar to the Y2K bug. Very soon the unique identifier associated to each tweet will exceed 2,147,483,6471. For some of your favorite third-party Twitter services not designed to handle such a case, the sequence will suddenly turn into negative numbers. At this point, they are very likely to malfunction or crash.

Time to haul out some BigInt action.

A rather cool piece of design, seen via Warren Ellis.