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.

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.

Tweet about this on TwitterShare on Google+Share on LinkedInShare on FacebookShare on RedditEmail this to someone

Speak Your Mind


Play CAPTCHA Audio
Reload Image