Encrypted E-mail Attachments Fixed in iOS 7.1?

Encrypted e-mail message with attachment on iOS 7.1

Signed and encrypted e-mail message.


 
S/MIME (Secure / Multipurpose Internet Mail Extensions) is one of two main methods of securing the content of e-mail messages between sender and receiver, regardless of the networks and servers that the message traverses along the way.  While S/MIME includes other functions, such as message integrity and non-repudiation, we’re going to focus on encryption today.

Where Can I Find It?
Though a small percentage of the general population are aware of how to implement and use S/MIME signing and encryption, the technology itself has been natively supported in most e-mail clients for some time.  Programs that support S/MIME include Microsoft Outlook, Mozilla Thunderbird, Novell Evolution, Apple’s Mac Mail, the iOS Mail App (in iOS 5 and later), and a small number of Android apps.  While perhaps used infrequently in the real world, S/MIME support is ubiquitous to the point that it would be hard to find a situation where it couldn’t be used if desired.

You Said iOS?
And then iOS 7 came along.  We talked here in late September about a problem that plagued Apple’s then-released iOS 7.0.  Incoming e-mail messages that had been created using S/MIME encryption, and which also carried file attachments, would often render those file attachments as pulsating and inaccessible when viewed on iOS 7 devices.  It wasn’t a universal failure, as encrypted messages created using Mac Mail on Mac OS seemed reliable.  Messages created using Microsoft Outlook and then read on iOS 7 – a scenario common in business – were the most prone to exhibiting the pulsating problem.  While the S/MIME attachment issue was brand new with the introduction of iOS 7, it persisted in nearly the same form for the next 5 months and 18 days, as we ran updates 7.0.2 through 7.0.6.

Who Cares?
To put the scope of the S/MIME attachment failure in perspective, my September blog post on the subject has pulled in 4,855 pageviews, representing 28% of the total traffic to this small blog since.  Readers have come from 1,665 networks, including those of well-known companies, government agencies, universities and medical institutions.  They’ve been a geographically diverse bunch, spanning 88 countries, from Andorra to Yemen.

At The Office
Closer to home, Apple’s S/MIME attachment handling problem was one hurdle standing in the way of potential wider adoption at my employer in Connecticut.  Using S/MIME under normal circumstances, I might automatically encrypt every outbound message to recipients with whom I’ve previously exchanged a signed message.  Since iOS 7’s release, however, I began having to make assumptions about whether the recipient might need to view an included attachment from an iOS device, and then send the messages in the clear to accommodate easy reading.  Such a limitation has glaring security issues, of course, and also places too high a burden on non-technical end users.  The technology needs to just work.

Fixed
As of this past Monday, it almost just works.  Following Apple’s release of iOS 7.1 on March 10th, I quickly upgraded an iPhone 4, an iPhone 5s and an iPad 3.  I should probably mention that I updated them using the ‘sync with iTunes’ method, rather than over-the-air.  From these iOS 7.1 devices, I’m now able to read PDF, XLSX and DOCX attachments on S/MIME encrypted messages sent via Outlook 14 / Office 2010.  Almost always.

New Issue
In cursory testing following the iOS 7.1 upgrades, I quickly saw at least three occasions where an attachment on a new encrypted e-mail message appeared to bear the filename of a previously-received attachment.  It was as if the messages were being decrypted to a common cache that isn’t always cleared properly after use.  In these rare instances where the wrong filename was presented for the attachment, opening the attachment was hit-or-miss.  I’ve only seen it happen three times so far, but anything less than 100% reliability doesn’t denote a complete fix.

Possible Resolution
So I called Apple to establish Case ID: 588543752.  The total call lasted 43 minutes, and I was quickly escalated to a Senior Advisor.  He took down my information to pass on to engineering.  Though I thought it unlikely to help at the time, I promised to wipe an iPhone 5s clean, re-apply my configuration profile, and confirm that I could still re-create the problem afterward.  Since wiping the iPhone 5s and setting it up from scratch, I’ve been unable to reproduce any problems with S/MIME encrypted messages bearing attachments.  This may turn out to be one instance where wiping an iOS device following a major upgrade actually does some good.  Stay tuned for more.  It’s never boring.

iOS 7 Mail App Flaw

Pulsating Attachment Problem in iOS 7 Mail App ©Apple Inc.

Pulsating Attachment Problem in iOS 7 Mail App ©Apple Inc.


 
It seems that relatively few people are aware of commonly-available standards and tools for end-to-end e-mail encryption, though more may be interested in this topic in the post-Snowden era in which we now find ourselves.  One of these standards – S/MIME – is natively supported in most e-mail clients, including Microsoft Outlook, Mozilla Thunderbird, Novell Evolution, Apple’s Mac Mail, and the iOS Mail App (in iOS 5 and later).  A small handful of colleagues, business partners and I use S/MIME signing – and encryption where applicable – in our day-to-day e-mail communications.  The fact that iOS has supported S/MIME for awhile makes it fairly seamless to use this technology, whether at our desks or on the go.  That is, until we all upgraded to iOS 7.

Having upgraded our iDevices to iOS 7 on or very shortly after the September 18th launch, we quickly noticed something strange with regard to encrypted e-mail.  We could read the body text of encrypted messages just as before.  Unlike with iOS 6, however, any attachments on these encrypted messages appeared to pulsate rapidly as seen above.  Trying to click on a pulsating attachment either results in nothing, or in the Mail app closing out abruptly.  Though the pulsing is fast enough to make it difficult to discern with the human eye, the attachment icon bearing the file type and name is sometimes interspersed with the word Downloading, the file name and a size that doesn’t seem to increment.  We’ve been unable to open any attachment exhibiting the pulsating behavior.

On Friday, we assumed that this affected all S/MIME attachments received on devices using iOS 7’s native Mail app.  I contacted Apple Support on case number 507281855, and also sent a message to a customer relations e-mail address that I’ve corresponded with in the past.  As we looked into the issue further over the weekend, it appears that e-mail messages created using Microsoft Outlook are most likely to exhibit the pulsating attachment behavior.  For instance, any test encrypted message that I’ve sent from fully-patched installations of Outlook in Office 2003 or 2010 arrive with the pulsating attachment problem on any iPhones and iPads running iOS 7.  When I created similar tests using Mozilla Thunderbird on Linux, two of three recipients received the attachment normally and were able to view it.  Further, any e-mail containing the content attached visibly in-line rather than as a file attachment seems to display fine as well.

So what do we know?  Every S/MIME encrypted message bearing a file attachment and created using Microsoft Outlook from a fully-patched installation of Office 2003 or 2010 exhibits the pulsating attachment problem when viewed on any iOS 7 device.  Encrypted messages with attachments created using Mozilla Thunderbird were readable by some – but not all – recipients using iOS 7 devices.  Encrypted messages sent using Mac Mail on Mac OS typically insert the attachments inline, where the content is viewable without issue.  Long story short, Apple’s Mail App has taken a step backward in iOS 7 where support for encrypted e-mail is concerned.  We can only hope that this is resolved in the next iOS update.

Update:

  • In the first week following this post, it was viewed 374 times from 209 cities in 32 countries.  Readers came from such roles as government (City of Los Angeles, Department of Homeland Security, NASA, and the U.S. Department of Energy), education (Bucknell University, Marquette University, Penn State, UC San Diego and University of California, Irvine) and Apple Inc. offices (Brisbane, Australia; Elk Grove, California; and Zurich).
  • A companion post over at the Apple Support Communities got 615 Views and counting.
  • Apple released iOS 7.0.2 to deal with security issues on the lock screen.  It did not address this problem.

Update 2:

  • Apple released iOS 7.0.3 on October 22nd.  It did not address this problem.

Update 3:

  • Apple released iOS 7.0.4 on November 14th, but did not fix this problem.  Following the upgrade on my iPad, I am not presented PDF attachments at all on S/MIME encrypted messages created via Outlook and sent via Exchange Server or Google-hosted IMAP accounts.  It’s as if they’re not there.  A Microsoft Word .DOC attachment still pulsates rapidly as in the original illustration.  My iPhone, however, shows both file types pulsating.

Update 4:

The FBI Needs An App For That

[The following post was written in the pre-Snowden era, and reflects a certain naivety on your author’s part, coupled with a desire to help my fellow citizens.]

Feelings come and go.  There are times when it’s easy enough to be skeptical of our government in general, and of their use use of technology.  It was only a week ago, for instance, that many of us observed this headline: IRS claims it can read your e-mail without a warrant.  So much for the Fourth Amendment.  But then there are days when tragedy strikes.  And on these days, such events bring out the best in nearly all of us.  We become a lot less self-centered.  We ask what we can do to help, even if it’s only to pray or to donate to the Red Cross.  The tragedy at the Boston Marathon on Monday was but the latest example.

In the wake of the events in Boston, many things are no doubt happening simultaneously.  Too many are still receiving critical medical care needed to save their lives, or to return them to their prior mobility.  Some lives have been altered forever, and three have been lost.  Much can be said for the medical and emergency professionals in Boston, then and now, doing what they do best.

Meanwhile, we know that local, state and federal investigators are working around the clock to determine exactly what happened.  The FBI is soliciting photos and video from any of the tens of thousands of spectators that were in downtown Boston leading up to the explosions.  Given the proliferation of smartphones in recent years, and the likelihood that countless photos and video were captured in the hours leading up to the blasts at this very public event, they’ve got their work cut out for them.  Gathering photographic and video evidence from citizen eyewitnesses may well be the easy part.  But it could be made easier, and better.

Our modern smartphones are somewhat uniquely valuable as evidence-gathering tools.  When you snap a photo on an Apple iPhone, for instance, you get a lot more than a high-resolution picture.  The image typically includes EXIF data that reveals many things, including your device make and model, its orientation, and the date and time that you took the photo, down to the second.  Since your phone’s time is often updated from the cellular network, those time stamps are reasonably precise.  Also included is your latitude and longitude, altitude, and even the direction you were facing.  EXIF tags could play a key role in algorithmically sorting the evidence, creating timelines and such.

In smaller investigations where smartphone-captured evidence is available, we can expect that an analyst would hook up the device and suck the contents to be sure that he or she got everything.  In a large-scale catastrophe, however, witnesses may well be submitting their evidence to agencies using a variety of means, and with mixed results.  Emailing photos from your phone may shrink them, giving up resolution that could be used to make a positive ID.  Importing them to your computer or manipulating images prior to upload can only risk losing some of the EXIF data or otherwise diminishing their evidentiary value.

Imagine, if you will, the following FBI smartphone app.  Given our acronym-friendly government, we could expect to call it something like FBI PIX (Public Information eXchange), for example.  Maybe it’s easier to think of it as an FBI Instagram.   This app would be freely available for every smartphone operating system, starting with iOS and Android.  When a major event occurs, a series of actions could begin in sequence…

  • The FBI would create a new event in their back-end systems for which they are requesting public submissions from anyone in proximity to the situation.  They could be ready to accept event-specific information almost immediately.
  • Any citizen who already has the app installed could receive a push notification with news and a request for photographs, video, or voice-dictated testimony.  At the same time, the media could alert anyone in possession of potential evidence to download the app if they haven’t already.
  • FBI PIX, as we’ll call it, would allow a phone’s owner to select photos and video directly from the phone’s photo stream or memory for submission.  They could be asked for additional information, including follow-up contact info such as an e-mail address and phone number.  Depending on the level of operating system integration, contact information might even be gathered automatically in some cases.  All evidence, including photos and video at their native resolution, containing all EXIF tags, would be bundled and transmitted directly to FBI servers using SSL encryption.
  • Submissions could be automatically logged into evidence, using the time and location data to populate an event data warehouse.  It’s likely that such an app could take steps to establish authenticity of evidence, and whether any in-camera image editing had taken place.  Chain-of-custody issues may be addressed as well.
  • All the while, users of the PIX app need no more technical knowledge than an adequate understanding of their phone and using apps in general.

Now there are obvious pitfalls to such a proposal, and we’re not going to try to cover them all.  There are those who wouldn’t be inclined to install any app from the FBI on their phone, for fear that it contained undocumented features that let the FBI spy on them.  For some, these concerns might be allayed by independent security audits.  Many would install the app only as needed, hopefully no more than once in a lifetime.  (It’s important to remember that we are still very safe here in America, relative to other locales and other periods in human history.)  And we probably wouldn’t want the app to enter everyday crime fighting use, pitting neighbor against neighbor as smartphone-toting informants.

For those Americans who find themselves thrust into the midst of a large-scale tragedy and soon ask what they can do to help, such an app may well be an opportunity to make a difference.  It could save the FBI time, especially in the early-going.  Ease of use could lead to more evidence submitted than might otherwise be the case.  EXIF data could be used to prioritize the flood of submissions for further human evaluation.  This could all serve as cords in the net that is ultimately thrown over the perpetrators of evil.

No doubt this hypothetical FBI PIX app is hardly an original idea.  And a team may well be working on it now, somewhere in Virginia.  Fortunately for all of us, Boston is the first time in years that such an app would be particularly useful.  Hopefully America won’t need it again for years to come.  Even so, now’s as good a time as any to get started.