Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iPhone OS 3.1 Blocking Encrypted Microsoft Exchange Connections on Non-3GS Devices
- Thread starter MacRumors
- Start date
- Sort by reaction score
They're not getting corporate enough. By that I mean, hey Apple, we corporate IT types would invite you in wholeheartedly if you didn't keep screwing up. Exchange support should be one of their highest priorities. Hell, it should be a division of Apple. They could be killing the Blackberry, but they are not winning any trust with this almost-good-enough Exchange support. The Blackberry, while it kind of sucks as a device in comparison to the iPhone, is still safe in corporations and for good reason: it syncs with Exchange with solid stability and is a highly functional Exchange client.
Welcome to MacRumors, which is considering changing its name to MacWhiners---I know pretty lame, but most of the forums are filled with whiners and you have to weed through to find the posts that are useful or intelligent. (my post should not be included in either of said categories--although it is more of a whine post, I'll admit).
All sorts of stuff are attached to emails in PDFs, Excel spreadsheets and Word docs.
I don't think Apple is being cynical about this. I think they just goofed, then fixed it. Just because MacRumors members can time travel
doesn't mean Apple can. Apple plans their releases well in advance but still can't be expected to have every feature of the next generation of a product in the current generation. That just doesn't make sense. Adding features in new models is what they do for a living and what we pay them for.I think people would whine less if they understood that this is a software fix for a real problem. But I also think that Apple could have been a little more forthcoming about this change in the Knowledge Base article.
OK, so Apple is obviously lying to get people to buy the latest model, but what exactly is it trying to convince people the latest model can do that earlier ones can't?
"Hardware encryption" isn't an answer, because there's no (classical) algorithm which can't be implemented in software on top of a general purpose CPU, and there exists no common algorithm which won't run fast enough on an iPhone's ARM CPU for the piddling amount of data involved.
"Hardware encryption" isn't an answer, because there's no (classical) algorithm which can't be implemented in software on top of a general purpose CPU, and there exists no common algorithm which won't run fast enough on an iPhone's ARM CPU for the piddling amount of data involved.
No heads up
Was this mentioned anywhere?
I appreciate they fixed a bug but I am upset as there was no real heads up.
Thankfully me company allows email forwarding so I can forward work email to a gmail account.
Was this mentioned anywhere?
I appreciate they fixed a bug but I am upset as there was no real heads up.
Thankfully me company allows email forwarding so I can forward work email to a gmail account.
Blackberry doesn't use ActiveSync. It uses the Blackberry Enterprise Server. Each device using the BES requires a purchased license. You can also use a desktop client but that isn't applicable in an "enterprise".
The issue is around Exchange 2007 w/ SP1. There is an option to enable device encryption in the ActiveSync policy. This tells the device that it should be encrypting cached email. Since the pre-3GS doesn't do this you now get an error whereas previously it just ignored it. Pre-3GS "could" do this in software but it would be very slow as encrypting/decrypting on the fly in software is *hard* on the CPU so it's not likely it will ever happen. The 3GS has specific hardware to accelerate this for a good user experience.
Your options are:
1. Find a way to roll back to 3.0
2. Corporate Exchange admin disables this policy rule.
3. Get a 3GS.
4. Don't use ActiveSync anymore.
Apple handled this 3.1 roll-out pretty pathetically. I believe they should of issued warnings to their users (especially enterprise users) that this update could stop ActiveSync for their entire pre-3GS iPhones. As it is most Exchange admins are probably finding out by their users screaming on the phone.
I'm not sure what the driving force was behind Apple changing their stance on this was. It's been fine since 2.0.
This is a side effect really, to keep out Palm Pre users, from iTunes...
That doesn't seem so far-fetched
.Other devices with slower CPUs have working software encryption implementations that don't degrade performance too much. And some of those devices, even with encryption enabled, are faster than the iPhone 3G...
If only certain content (such as the mail, SMS, calendar, contact list, cookies, and network settings) needs to be encrypted, then the performance impact could be slight enough to be unnoticeable.
It may be a fix for a problem, but they sold a ton of 3G's that supposedly had exchange support, plan and simple. Clearly if they did not build in hardware encryption, they did not actually build in true exchange support and 3G owners have a very valid beef with apple because they were actively deceived in countless ads and spec sheets touting the 3G's compatibility with Exchange servers. Clearly when working properly (i.e with encryption enabled) there is a blatant incompatibility given the apparent lack of hardware encryption on earlier iphone models. I applaud apple for releasing a fix for a security problem, but if that fix is not accompanied by a hardware fix its essentially disabling a feature 3G owners believed their phones were capable of. Should apple choose to leave this as it is, they risk loosing what little support in the corporate world they had.
How someone at apple did not at least think to include a warning in the update dialog at the very least is unreal.
I think it's obvious that apple could have handled this a whole lot better, that hopefully goes without saying.
As for this change making the 3G incompatible with Exchange, I'm not sure that is fair. The device encryption setting is a policy setting that administrators can choose to activate and should appreciate the implications of prior to doing so, because it also means that the Exchange server cannot sync with older windows mobile devices.
For me its simple - if your employer needs devices to be using this setting then they need to count on it working and its a good thing Apple have fixed this bug. If your employer doesn't actually need devices to be using this setting then any admin who turns it on anyway needs to ask themselves why.
Its funny that exchange encryption runs entirely in software on Windows and Snow Leopard then isn't it? In fact I'd bet that its done in software on the iPhone 3GS as well.
The only reasonable possibility for not supporting this on the older iPhone models is that they don't have the CPU resources to handle the encrypting and decrypting on a reasonable user friendly timescale. However I really don't buy that. Its more likely simply corporate greed.
Apple apologists: continue to apologise away.
No, the 3GS has hardware level encryption support of the entire data partition. The encryption/decryption is handled by a separate chip which is why the 3G and 2G iPhones do not support that feature.
This is not just encryption of individual files but on a disk level.
Where is the documentation explaining that the Exchange policy requires the "entire data partition" to be encrypted? Where on microsoft.com is the "Require encryption on this device" policy defined? Why can't there be an encrypted partition (container) for Exchange?
While I'm here, what is the iPhone thrashing to/from flash which means a standard symmetric crypto algorithm can't be run in s/w on all local storage? I propose ROT13 for binaries to fix the no-background-apps bug without affecting launch time. Does the Exchange policy prohibit varying the crypto by file?
1) Yes, incredibly stupid. Unless we move on to some sort of TPM/Trusted Computing system, trusting the client side to provide important information is always a bad idea as they can always modify it. That's like setting the price of a service/good for a shopping cart platform via hidden form values... The client can change them before they submit the form, and if no server side verification is done, boom, cheap/free product! (Incidentally, tons of people do this... I'm guilty of coding pages like this myself.)
I doubt OS 3.0 on the 3G lied to the exchange server, though it's possible; More likely is that it simply didn't reply to the server's "Device Encryption Supported?" question and the server just assumes it does in the event of no reply and moves on... Sounds like 3.1 actually replies with a proper yes/no response.
2) Of course they can. Anything that can be done via hardware can be done via software on a general purpose processor like the arm. They're just not going to because a) It would increase the base system's memory footprint, which is already a problem on the 2G/3G devices b) it would use battery life up c) it would be slower d) it would require using developer resources to implement and maintain the code branch e) it would remove a selling point for their new models.
It's e) that's the kicker. If your enterprise really requires device encryption, they're going to require the 3G
If not, just turn the feature off.
Device encryption is a joke as it is anyways... Sure the data gets stored on the device in an encrypted manner... but as soon as the device is on it starts decrypting it so that it can actually be used... So unless you require a (secure, not 4 digit...) key everytime the device is unlocked or turned on, then there is no way to secure the data from being extracted, unencrypted, by using the phone's OS itself.
And even if you do require a secure password at unlock/startup and properly freeze the memory states, etc... the device is still vulnerable when it is in use.
Is it your personal iPhone? If so and if your employer requires hardware encryption on portable phones, why would you be allowed to use your personal iPhone for work email in the first place?
Device encryption is hardly a joke; a proper implementation will protect information if the device is lost or stolen. With a proper encryption implementation, the information on a powered-off device is useless. Even with a 4 digit numeric password, a proper encryption implementation will simply erase the key after a few invalid password attempts. Bypassing this would require an attacker to copy the contents of flash and attempt to crack offline, and a well designed device will need to be disassembled to do so.
If the encryption key is stored in RAM while the device is running (as in Windows Mobile's implementation and OS X/Windows full disk encryption implementations), any vulnerabilities have to be in the OS itself - assuming the device is locked, the device has to be compromised somehow without rebooting it.
BlackBerries can be configured to clear the encryption key from RAM when the device is locked. Even if the password screen was somehow bypassed, the content would be inaccessible.