Introduction to S/MIME
Secure MIME is the de-facto standard for securing email communications in the enterprise today. S/MIME can authenticate the sender of an email and guarantee the integrity and confidentiality of an email message through signing and encrypting the content of an email (body, attachments and headers).
In this white paper, we will go through the fundamentals of the S/MIME protocol, its challenges and explain how AirWatch can help your organization with deploying S/MIME securely to your mobile fleet.
Note: Some basic knowledge of Public key infrastructure (PKI), certificates, encryption and hash algorithms are required for fully understanding the next sections.
S/MIME signing allows the recipient (Alice) to verify that the sender (Bob) is indeed the sender of the received email. Hence, Bob needs to compute and add a digital signature (see below), that only he knows how to compute, to the content of his email. Figure 1 depicts the S/MIME signing process.
Note: A digital signature is an encrypted hash of the message to be signed. The hash function allows validating the message’s integrity as it is a one-way function, while the encryption guarantees the owner of the signature as encryption is performed using the owner’s private key.
Figure 1: S/MIME signing process
A man-in-the-middle intercepting and altering the content of the email is unable to compute a new signature as he does not have access to Bob’s private key. Alice would notice a mismatch in the signature and conclude that the email message has been compromised.
S/MIME encryption ensures confidentiality by encrypting an email’s content. Bob uses Alice’s public key to encrypt (typically RSA) the symmetric session key used to encrypt the message’s content. Figure 2 depicts the S/MIME encryption process.
Figure 2: S/MIME encryption process
Challenges around S/MIME
There are three main challenges around S/MIME on mobile devices:
- Retrieving the S/MIME certificates from the company’s Certificate Authority.
- Deploying the S/MIME certificates securely to mobile devices.
- Enabling S/MIME outside of your organization to securely communicate with external parties.
Challenges around S/MIME certificate retrieval
PKI best practices assume that users should not have direct access to their certificates’ private keys. This is to ensure that the private key is only available to software requiring it (e.g. an email client) and cannot be exported. In order for S/MIME to work efficiently, key archival needs to be in place on the PKI infrastructure in order for the private key to be retrieved and securely installed on the mobile device’s email client for already received emails to be decrypted. This also requires that the S/MIME certificates can be retrieved from the Certificate Authority either manually and/or programmatically.
Challenges around S/MIME certificate deployment
As certificates with private keys are required to be sent to the mobile devices, particular caution needs to be applied when transmitting the certificates. Security in-transit and at-rest needs to be verified to prevent the loss or interception of the certificates and their private keys. In this way, if there are any intermediaries between the Certificate Authority and the email client on the mobile device, you must ensure that the certificates are not stored longer than necessary at any intermediaries. Additionally, a secure process (for instance 4-eye principle) should be in place to ensure that the end user is not misusing his private during the S/MIME certificate provisioning process.
Note: The 4-eye principle consists in having two individuals approving some actions before they can be taken.
Enabling S/MIME outside of your organization
As previously discussed, encryption is done with the recipient’s public key while signing occurs with the senders private key. If the sender and the receiver of an S/MIME secured email are within the same Directory, then they will obtain their counterpart’s public key certificate by querying the Exchange ActiveSync server via ActiveSync. If they are not members of the same organization, then the sender has to obtain the receiver’s public key in alternative ways. A typical way is the exchange of certificates (public key) as part of a non-S/MIME email. The sender adds the receiver’s certificate (public key) to his contact record and can then use it to encrypt emails.
Disparate support of mobile email server clients
The last challenge around mobile S/MIME is the heterogeneous support in mobile email clients and infrastructure. S/MIME remains widely unsupported and requires extensive testing across the target different mobile platforms / email clients. While some native email clients support S/MIME on specific platforms (native iOS, Samsung SAFEv4+), other devices require a specific email app/client (AirWatch Inbox).
Supported Email Infrastructures and Email Clients with AirWatch
The following non-exhaustive list summarizes the requirements for deploying S/MIME.
Microsoft Exchange 2003 – 2007 – 2010 – 2013
As of May 2015, IBM Traveler (9.0.1) does not support S/MIME and offers an alternative way for securing email relying on the user’s Notes ID. This approach is limited to internal communications.
Mobile email clients
AirWatch can enable S/MIME on following email clients:
- iOS: Native iOS email client, AirWatch Inbox,
- Android: Native (Samsung SAFEv4+ only) email client, AirWatch Inbox
- Windows 8.1: AirWatch Inbox
- Windows Phone 8.1: Partial support in native email client
Enabling S/MIME in the Email Configuration Profile
A configuration profile with two enabled payloads is needed for enabling S/MIME in the email client of choice.
The Credentials payload allows administrators to specify certificates to be used for signing and/or encryption. AirWatch supports signing and encryption with same certificate as well as signing and encryption with 2 separate certificates.
The first step in rolling out S/MIME is to configure the Credentials payload in Menu > Devices > Profiles > List View > Add > Select [iOS|Android|Windows 8.1] > Credentials.
Figure 3: Enabling the S/MIME Signing certificate
Figure 4: Enabling the S/MIME Encryption certificate
‘User Certificate’ means that the certificate will be pulled from the user’s object in AirWatch. Once the Credentials payload is configured according to your setup, you can move on to configuring the Exchange ActiveSync payload.
Exchange ActiveSync Payload
To enable S/MIME, first select the email client you want to deploy and check the “Use S/MIME” box.
The Deployment Type in the payload “General” needs to be set to “Automatic” for this setup to work. AirWatch will wait for the S/MIME certificates to be provisioned (see next section) before pushing down the dormant email profile.
Figure 5: General payload for S/MIME profile
Alternatively, the Deployment Type can be set to “Optional” if you are planning to push the profile to devices via API, see Section “Automatic upload of the S/MIME certificates via AirWatch REST API” in the next part.
Different Options for Deploying S/MIME Certificates with AirWatch
AirWatch will not push the previously created email configuration profile until the S/MIME certificates are uploaded in the user’s object. This can be performed in three ways.
S/MIME certificates upload in the AirWatch Console by an Administrator
The first way to provision S/MIME certificate to mobile email clients is by uploading them into the user’s object in the AirWatch Console. In this scenario, a console’s administrator is required to have access to the user’s S/MIME certificates in .p12/.pfx format and know the certificate’s passwords for upload in the AirWatch Console.
- Edit the target user’s account In Menu > Accounts > Users
- Check the “Show advanced user details” box and enable “Use S/MIME”
Figure 6: Add/Edit User to upload S/MIME certificates
3. Upload the S/MIME Signing and/or Encryption certificates to the user’s object. The certificate’s password protecting the private key is required for the upload to complete. As S/MIME certificates usually have shorter validity periods as authentication certificates, users can come across scenarios in which they are unable to decrypt older emails. There is an additional option in the user’s object to upload the user’s historic encryption certificates in order to enable the decryption of emails encrypted with older public keys.
Figure 7: S/MIME encryption certificate history
- Users do not get access to their S/MIME certificates and cannot misuse them as they are unlikely to know how to protect them
- Few console administrators have access to many S/MIME certificates
- Additional processes are required for Administrators to be able to obtain S/MIME certificates on behalf of their users
- High administrative overhead as manual process, especially at renewal
S/MIME certificates upload in the AirWatch Self-Service Portal by the end user
To avoid the additional administrative overhead mentioned in the previous method, AirWatch provides an S/MIME certificate upload process within the Self-Service Portal (SSP). The end-user is required to have access to their S/MIME certificates and upload them in the AirWatch SSP, resulting in the S/MIME-enabled email configuration profile (see Part II) to be pushed down to the device.
- User navigates in a browser to the Self-Service Portal and logs in (usually on desktop computer or laptop): https://airwatchenvironmenturl.tld/mydevice
- Select the Advanced Actions tab.
- Select the Upload S/MIME Certificate option.
4. Upload the S/MIME certificate(s).
- No more administrative overhead as end-users upload their certificates themselves
- Simple and scalable process
- End-users are required to have access to their certificates and privates keys (in .p12 or .pfx format). A 4-eye principle is recommended to prevent the misuse of the certificate and its removal form the user’s computer.
- Manual process requiring input and buy-in from end users to complete required actions.
Automatic upload of the S/MIME certificates via AirWatch REST API
In this process, the S/MIME certificates are programmatically uploaded into AirWatch via a REST API.
- User enrolls the devices.
- AirWatch sends event notifications (also called webhook) to PKI Connector exposed to AirWatch over a secure channel by the customer to notify the enrollment.
- User’s S/MIME certificates and password are programmatically retrieved from the PKI and uploaded into AirWatch via REST API (documented at https://airwatchenvironmenturl.tld/API/v1/system/users/help/resources/UploadSMIMECertificates). The programmatic retrieval of S/MIME certificates requires the Certificate Authority to support key escrow.
- As soon as AirWatch receives the certificate, the S/MIME profile is pushed down to the device including certificates and passwords obtained in step 3.
- After the email profile is successfully installed on the device, S/MIME certificates and passwords are removed from AirWatch database as per best practice to ensure certificates exist in least number of locations possible.
- Repeat steps 3 and 4 if certificates need to be updated on the device.
The following diagram represents an overview of the API method flow.
Figure 8: S/MIME certificates upload via API
The uploadsmimecerts API takes following arguments in JSON or XML format:
Figure 9: uploadsmimecerts API example request
- Fully automated and secured process with no user interaction
- Administrators and end users do not get S/MIME certificates as .p12/.pfx files in their hands
- Requires programming to create the webhook listener, the programmatic certificate retrieval and the uploadsmimecertificates REST API
S/MIME certificate sent as an email attachment
In this (not recommended) process, the user can receive his S/MIME certificates as email attachment in the AirWatch Inbox. The installation process is shown below.
- The S/MIME certificate and password are not stored together in the AirWatch database
- User has access to her certificate’s .p12/.pfx file and can misuse it by forwarding or maliciously
As of April 2015 and AirWatch v8.0, this process is only supported by the AirWatch Inbox on Windows 8.1 (v1.4).
The following matrix summarizes the supported options for S/MIME on mobile devices.