VMware Boxer’s new FastSync tech could usher in a better third-party email experience
Jon Towles explains how VMware Boxer uses key escrow to solve this long-time problem in a thoughtful and secure way.
Going back to iOS 7, email has been a major pain point for users. Over the years, many of the key players (like TouchDown) have started to dissipate , leaving users to scramble for a next-level email experience that matches their desktops. No one has come close to delivering on this vision. Apple has never truly let third-party apps sync in the background and Apple’s interpretation of ActiveSync via their native Mail app has always fallen short. VMware may have finally combined the strengths of native email and third-party email into a cohesive and consistent experience by introducing a new spin on an old friend, FastSync.
iOS and key escrow
For those of you who have read the iOS Security Guide, which I’ve written about before, you may have overlooked a small portion talking about escrow keybags and escrowing of keys altogether. We will talk more about that later, but, in the MDM world, it has been used to allow your MDM vendor to remotely clear the device passcode for a user who may have forgotten it.
Third-party email applications have two major requirements in the modern era: provide email notifications and sync email in the background. A major challenge that no one has been able to solve is the second one when the device is locked because of Apple’s data protection model and the inability to write to the application database when locked.
Some companies are leveraging the Exchange subscription model for notifications as a nice middle ground, but that’s just not enough for the demands of customers today. Even with that in mind, some companies like Microsoft have done things in a way that do not make customers comfortable, such as with their Outlook service that caches a copy of your device’s mailbox in Azure Blob Storage that you have zero insight into. So, let’s talk more about how VMware hopes to solve these problems a bit more elegantly.
How are iOS apps encrypted?
Email applications typically use the iOS data protection class called “Complete Protection” which means data is only available when the device is unlocked. The item’s class key is protected with a key built from a combination of the user passcode and the device UID. Shortly after the user locks a device (10 seconds, if the “Require Password” setting is Immediately), the decrypted class key is discarded, rendering all data in this class inaccessible until the user enters the passcode again or unlocks the device using Touch ID or Face ID.
What is key escrow?
Apple designed the concept of key escrow for a few use cases, which are typically for iTunes synchronization/software updates and for clearing passcodes on an MDM solution. Essentially, a keybag (a collection of file and Keychain Data Protection classes) is generated and stored on your MDM solution.
Another example of key escrow on iOS is when devices pair with a Mac. When the devices pair, they create 2048-BIT RSA keys (one on the devices and one on the server) which are used in a similar fashion to public key exchange operations, such as email encryption. This ensures that it will take “two to tango.” I’d definitely recommend reading more about it in the iOS Security Guide.
How is key escrow implemented with MDM solutions?
In MDM development for iOS, you store two different bypass codes (one generated by the device and one generated by the server). When trying to bypass the passcode, it will try to use the one most likely to be active (based on timing). A nice example you can see below, shows your MDM activating activation lock by passing the escrow key to bypass:
It’s a good read in their MDM Protocol Reference, which is essentially the bible for MDM implementations with iOS.
How VMware Boxer solves this issue
Those who know me have likely read several articles that I’ve written about Boxer over the last few years. I wrote a comparison of Boxer and Outlook for iOS, for example, where I break down the two platforms. I’ve had the good fortune of building good relationships with Evan Hurst and Max Blinder at VMware over the last few years and their great developers like Kris Wong and Rod Struogo want to have a real impact in some of the aspects of their roadmap, trying to get Boxer to a point where it was a best-in-class solution. It’s been hit or miss if I’m being honest; but, they do a much better job of remediating issues than Microsoft. I’ve seen several issues in the last three years that Microsoft has taken one to three months to fix (like this issue here), whereas VMware would deliver fixes very quickly and often make the IPA/APK available to remediate users quickly. That is a MAJOR value for enterprises and that is indisputable.
I’ve gone back and forth with Boxer as some issues (not all of their fault) have come up that made me table Boxer. Now that WebEx made it so you can directly integrate WebEx with O365 via OAuth, I started looking into what they have been working on. I was glad to see that Boxer 5.7 currently in beta, is introducing the concept of key escrowing with Boxer. This starts with deploying a few KVPs (Key-Value Pairs) to extend key escrow to the application via managed app configuration detailed by the App Config for Enterprise group.
The keys you will see below let you enable this feature with ENSEnableKeyEscrow and specify how long before the short-lived key expires in hours with ENSKeyEscrowExpiry.
How key escrow works in VMware Boxer
VMware is introducing a new technology called FastSync. To understand how it works, we should start with the technology involved. VMware is leveraging a KEK (Key-Encryption-Key), which is escrowed to VMware’s Email Notification Service v2 (ENSv2) and used to decrypt the database key for Boxer. (You can read more about ENS here.) The KEK’s job is to encrypt the DB key and store that encrypted value in the keychain. This makes it possible to write to the Boxer application while it is locked. The concept is solid because it maintains the integrity of the DB key, thus providing confidentiality protection. Internally, VMWare refers to this as the background sync key, which has a finite lifetime as specified in the KVP: ENSKeyEscrowExpiry mentioned earlier.
The key is renewed every time the device is unlocked, which shows that VMware has done a nice job balancing user experience with security. You can easily do things in a terrible way that compromises the security posture of your device. It’s so crucial to mitigate risk and have options to pressure the integrity of your operating system. VMware could have easily just exposed the keybag used to clear the device passcode, but they went the extra mile. They also added spam reporting and mapping to a spam mailbox, but that’s not what the point is here!
What does it mean?
I definitely believe that ENSv2 coupled with the ENS Key Escrow feature has helped them to overtake Outlook for iOS yet AGAIN as the elite email platform for iOS. It doesn’t help Outlook with some of their small gaps and the ineffectiveness to remediate issues promptly.
Outlook has made some nice moves with things like their caching services, but one of the top things I hear from companies is a constant frustration with how emails don’t download until you open the mailbox. I know it sounds silly, but we do live in a culture of “NOW, NOW, NOW!”
At the end of the day, key escrowing can be done poorly or can be done brilliantly, but why is it not done more? It’s easy to say, “Apple doesn’t let it do it,” but it’s something else entirely to push the frameworks available to us to deliver an amazing experience. This is what makes mobile so compelling as an architect.
