Yesterday I published an article over at TidBITS describing how Apple’s implementation of encryption on the iPhone 3GS is flawed, and as a result you can circumvent it merely by jailbreaking the device. In other words, it’s almost like having no encryption at all.
Over on Twitter someone mentioned this was discussed on the Risky Business podcast (sorry, I’m not sure which episode and can’t see it in the show notes) and might be because Apple intended the encryption only as a remote wipe tool (by discarding the key), not as encryption to protect the device from data recovery.
While this might be true, Apple is clearly marketing the iPhone 3GS encryption as a security control for lost devices, not merely faster wipes. Again, I’m only basing this on third-hand reports, but someone called it a “design feature”, not a security flaw.
Back in my development days we always joked that our bugs were really features. “No, we meant it to work that way”. More often than not these were user interface or functionality issues, not security issues. We’d design some bass ackwards way of getting from point A to B because we were software engineers making assumptions that everyone would logically proceed through the application exactly like us, forgetting that programmers tend to interact with technology a bit differently than mere mortals.
More often than not, design flaws really are design flaws. The developer failed to account for real world usage of the program/device, and even if it works exactly as planned, it’s still a bug.
Over the past year or so I’ve been fascinated by all the security related design flaws that keep cropping up. From the DNS vulnerability to clickjacking to URI handling in various browsers to pretty much every single feature in every Adobe product, we’ve seen multitudes of design flaws with serious security consequences. In some cases they are treated as bugs, while in other examples the developers vainly defend an untenable position.
I don’t know if the iPhone 3GS designers intended the hardware encryption for lost media protection or remote wipe support, but it doesn’t matter. It’s being advertised as providing capabilities it doesn’t provide, and I can’t imagine a security engineer wasting such a great piece of hardware (the encryption chip) on such a mediocre implementation.
My gut instinct (since we don’t have official word from Apple) is that this really is a bug, and it’s third parties, not Apple, calling it a design feature. We might even see some PR types pushing the remote wipe angle, but somewhere there are a few iPhone engineers smacking their foreheads in frustration.
When a design feature doesn’t match real world use, security or otherwise, it’s a bug. There is only so far we can change our users or the world around our tools. After that, we need to accept we made a mistake or a deliberate compromise.
Reader interactions
2 Replies to “Not All Design Flaws Are “Features””
Yoshi, as I said in the article I’m not attributing that design comment directly to Apple.
Incremental doesn’t work in security- it works or it doesn’t. And if it’s being advertised as a working feature, then we expect full functionality. Agree completely that that isn’t necessarily true in other areas of software development. I’d even agree if they hadn’t advertised the hardware encryption to enterprise customers. But they did, and it should work properly.
Who is calling it a design feature? Certainly not Apple by my 5 second review of the iPhone page on their site. And your definition of ‘bug’ is … interesting.
What you seem to be missing is that Apple designs features into their products incrementally. This reminds me of the howls of protest when Apple released version 1.0 of iPhone and didn’t include an SDK. And when they released the API the world stated that Apple “caved” to pressure and released an SDK. Apple always intended to released an SDK. It just wasn’t ready day one. And Apple has been improving the security of the iPhone and adding other functionality step by step. My take is that the software just wasn’t ready and Apple will release additional features that take advantage of that chip in later releases. They can’t dance on RIMs grave until they do so.
So not a bug just something not fully utilized.