iOS 5, Apple’s new operating system for iPad, iPhone, and iPod Touch, will be released “soon” – Apple officially says “this Fall,” and many prognosticators are pointing to sometime in October. While the new release has hundreds of new features, the feature that’s of particular interest to digital identity practitioners such as CSS is one that’s received very little press to date: S/MIME.
The current version of iOS4.x supports the use of digital certificates for authentication: to things like wireless networks, VPNs, and Microsoft ActiveSync . But starting with iOS 5, iPhone, iPad, and iPod Touch users will be able to send and receive digitally signed and encrypted email messages directly from their device.
This is a big step, which again raises the level of relevance for iOS in the Enterprise space. However, even under the simplest of circumstances, S/MIME deployment planning should not be taken lightly. S/MIME in conjunction with mobile devices ups the ante of complexity even more.
Our goal here is to outline some of the planning and deployment considerations associated with an S/MIME rollout that involves iOS devices.
A Brief Overview of S/MIME
As a protocol, S/MIME (which stands for “Secure Multipurpose Internet Mail Extensions”) has been around since the late 1990’s – almost as long as SSL – and it is natively supported by almost every popular email client. Yet it has not enjoyed anywhere near the same level of ubiquitous adoption as SSL.
Why is this? The answer probably lies in the way that S/MIME works. Significant factors include:
- The recipient needs a certificate: Due to the way public key cryptography works, a message is encrypted with the recipient’s public key from their certificate. Only the recipient’s corresponding private key can decrypt the message. This means that if you’ve just deployed PKI, or purchased an email certificate from a third party, you are not necessarily any closer to being able to send S/MIME-encrypted mail. If your intended recipient is outside of your organization and does not have an email certificate, you’re out of luck.
- You need to have the recipient’s certificate: It sounds simplistic, but at the time that you’re ready to send the message, your email client needs to have the recipient’s certificate readily available, so that it can use their public key to encrypt the message. If they’re internal to your organization, their cert can probably be looked up in an enterprise directory. But if not, you may be out of luck again. Most email clients do have an ad-hoc way of sharing certificates, by exchanging digitally signed emails with your intended recipient first. But this is not always practical or scalable. As a result, many S/MIME deployments are focused on internal-only encryption scenarios.
- Old Private Keys Need to be Kept Around: When a user’s certificate expires and they enroll for a new one, the old one cannot be deleted, or the user won’t be able to read any email that was encrypted by the old certificate.
- Private Keys Need to be Archived: Any time you plan on keeping data on disk encrypted form – and encrypted email is a prime example – you will need to have a solid key archival and recovery plan, or you are risking data loss. If a user loses their private key, or is terminated, retires, etc., their email still needs to be accessed. In many cases this is a Data Retention requirement, with legal or compliance ramifications.
- Separation of Certificates: Encryption certificates need archived private keys. But authentication or signature certificates have the opposite requirement when it comes to key protection: for digital signatures to have “non-repudiation” value, you want to be able to say that the user, and only that user, had access to the private keys… which is of course impossible if the keys are archived and recoverable by others. This is why most email clients support the use of separate email certificates: one for email encryption and a different one for signing. But unlike encryption certificates, there is no risk of data loss from a lost signature certificate; you can just issue a new one.
S/MIME and iOS
Fortunately, all of the above is doable, with the proper planning. CSS offers the following suggestions for a general approach to supporting an S/MIME deployment involving iOS 5.
Enroll for Authentication and Signature Certificates using SCEP: iOS devices natively support the Simple Certificate Enrollment Protocol (SCEP)… and so do a number of Certification Authorities, including the Microsoft CA. SCEP-enrolled certificates from iPhones and iPads their private keys generated on the device itself, and they can never be exported. If the device is protected by a passcode, you have a relatively good non-repudiation story. In addition, authentication certificates are typically used to authenticate to internal systems such as VPN and wireless networks, which means that a publicly-rooted PKI is unnecessary.
DO NOT Enroll for Email Encryption Certificates Using SCEP: Enrolling through SCEP prevents the ability to archive the private keys. In addition, in order to read email in multiple locations, each user needs to have exactly one active email encryption certificate at any given time: every system that the user reads their email on needs to have the same certificate and private key, and everyone that sends email to them needs to be using that certificate when sending encrypted mail.
Email encryption certificates must therefore be generated elsewhere, and securely imported into the device. But enrolling users for certificates on their laptops or workstations and then migrating their keys to the device poses additional challenges. If at all possible, private keys for end-users should not be marked as exportable. It’s too easy for users to export them and move them to places where they don’t belong. In addition, most users choose lousy passwords to protect the exported keys, and don’t delete the files when they are finished with them, leaving them at great risk of compromise. CSS strongly recommends leveraging a centralized key archival and recovery solution.
The preferred approach, then, is to have an automated solution that can enroll and/or deliver a user’s current and past S/MIME encryption certificates to their iOS device with minimal effort on their part.
Certificate Management Planning
Certificate Management remains one of the more under-addressed aspects of PKI-enabled application deployment. Before any enterprise application is deployed, careful consideration should be paid to aspects such as:
- Certificate Enrollment: How will certificates be enrolled and delivered?
- Certificate Expiration: What happens when the certificates expire? Who’s responsible for handling the update of certificates, and what will that process look like?
- Certificate Revocation: Will these certificates need to be revoked in certain circumstances? If so, what are they, who is responsible, and how will it be handled?
- Certificate Loss: What is the replacement plan if a certificate is lost? If encryption certificates are in use, the exact certificate (or at least a cert with the same private and public keys) will need to be recovered and delivered back to the user. Depending on the types of certificates involved, this may also include a revocation discussion as well.
Because of its complexity, S/MIME on mobile devices requires particularly careful certificate management planning. For example, iOS takes no action whatsoever in terms of re-enrolling or notifying the user when their certificate is approaching expiration. Nor does it do anything when the cert actually expires for that matter.
Putting a Solution Together
Keyfactor has been tackling challenging problems for large enterprise customers for over a decade, through a combination of off-the-shelf products, professional services, and our own products and tools. In large part, the components for a comprehensive solution to the challenges mentioned above already exist. We envision a solution involving the following products:
- A Public Key Infrastructure based on Microsoft CA software to create and deliver certificates to the necessary players. SCEP will be supported via the Network Device Enrollment Service (NDES) role on Windows Server 2008.
- Microsoft Active Directory, which controls certificate content and enrollment criteria, and stores users’ enrolled email certificates for use with email clients such as Outlook. iOS 5 can automatically retrieve recipients’ certificates from Active Directory through its native Exchange email connector.
- Microsoft Forefront Identity Manager – Certificate Management: A lesser-known component of Microsoft’s Identity Management suite, “FIM-CM” provides scalable workflow and automation over the certificate lifecycle events mentioned in the section above – particularly private key archival and recovery.
- The Certificate Reporting Tool (CRT) from Certified Security Solutions, which helps monitor Microsoft CAs for expiring certificates, and notifies certificate holders or administrators about impending certificate expiration. CRT also provides a pluggable, flexible framework for performing customized actions related to certificate handling. More information on CRT can be found here.
- Certified Security Solutions’ Mobile Certificate Management System (mCMS): set to be released in October 2011, mCMS allows for smooth automation of SCEP-enrolled certificates without opening up potential security vulnerabilities. More technical information regarding mCMS can be found here.
- Apple’s iPhone Configuration Utility (IPCU), which allows administrators to create baseline configuration profiles that are used by CSS’ mCMS.
- Visit the Mobile Certificate Management System (mCMS) page here.
