S/MIME for Military and High-Security Messaging

Why S/MIME for Military Messaging?

Military messaging needs to use open standards for secure communication, in order to support interoperability between independent organizations and partners. This gives two choices for SMTP based messaging. PGP (Pretty Good Privacy) is useful for providing security for ad hoc email communications, but is not appropriate for managed communications and does not provide many of the capabilities discussed below. S/MIME is really the only viable option. It operates based on a Public Key Infrastructure (PKI) which is likely to be a key capability in the target environment.

Commercial Deployment of S/MIME

S/MIME is available on a wide range of desktop and mobile clients, including Microsoft Outlook, Outlook Express, Windows Live Mail, Entourage, Mozilla Thunderbird, Apple Mail, Novell Evolution, Eudora, IBM Lotus Notes, and Apple iPhone Mail. It is less widely supported on Webmail, but is available in Outlook Web Access and using plugins such as Penango for Gmail.
When sending an email message, the S/MIME user will typically be presented with two options.

1. To digitally sign the message (using the user’s private key). This digital signature will:
   • Provide recipients of the message with a way to be certain of the sender's identity. This “origin authentication” service helps to detect message forgery.
   • Provide "message integrity", so that recipients may be confident that messages they receive have not been tampered with.
2. To encrypt the message, which is done by using a symmetric cipher (see below), whose key is protected using the recipient's public key. Since a message encrypted in this way can only be decrypted with the recipient's private key, it cannot be read by anyone other than the intended recipient.

These are the central “secure email” services. These two services will typically suffice for a basic commercial email deployment. This paper explores the additional services that are needed for military and high security messaging environments.

Key S/MIME Standards

The following standards are used with S/MIME.

• Asymmetric Cryptography is central to S/MIME. S/MIME will typically use one of RSA, DSA or Elliptic Curve algorithms. An S/MIME user will have a private key held privately, often on a smart card. This private key is used for signing and decrypting messages. The associated public key is made available using Public Key Infrastructure (PKI).
• Symmetric Cryptography. Asymmetric cryptography has too high a performance overhead to be used for encrypting messages. Messages are encrypted using symmetric cryptography, with asymmetric cryptography used to protect the secret key. Advanced Encryption Standard (AES) is a symmetric algorithm commonly used with S/MIME.
• Cryptographic Messaging Standard (CMS) specified in RFC 5652 is a format that provides flexible capabilities for signing, encrypting and related capabilities. It provides the key security functionality underlying S/MIME, but can also be used independently of S/MIME. In particular, it is used for providing security in STANAG 4406 military messaging.
• Secure/Multipurpose Internet Mail Extensions (S/MIME) is specified in RFC 5751. S/MIME defines how to use CMS security with MIME, which is the standard format of data carried in SMTP email. There are two basic approaches:
  • “Opaque”. This simply includes CMS data as a body part. It will always be used for encrypted data, and is the simplest option for a signed message.
  • “Clear Signed”. This uses the multipart/signed approach to sign messages. This format has the advantage that it can be processed by email clients that are not S/MIME capable.
• Enhanced Security Services for S/MIME (ESS) is specified in RFC 2634. This covers a number of the capabilities described in this paper to extend basic S/MIME security.

Header Signing & Encryption

The following screenshot shows a message sent using Microsoft Outlook. The valid digital signature is indicated by the rosette. We will now look inside this message.

From: "Steve" <XX@isode.com>
To: "Steve" <XX@isode.com>
Subject: Demo
Date: Tue, 12 Nov 2013 15:21:59 -0000
Message-ID: <023501cedfba$ee6d1380$cb473a80$@isode.com>
X-Mailer: Microsoft Outlook 14.0
MIME-Version: 1.0
Content-Language: en-gb
Content-Type: multipart/signed;
protocol="application/x-pkcs7-signature";
micalg=SHA1;
boundary="----=_NextPart_000_0230_01CEDFBA.EE33B400"

This shows the message headers and then the start of the digital signature. In this message, the only information that is signed is the message text ("Steve"). The message headers (including From: To: and Date: ) are not signed. This is how all commercial email clients (that we are aware of) work.

Message headers often carry critical information: in high security environments it will be important to ensure that they are not tampered with, and it may also be important to encrypt them. For military messaging, additional headers are likely to be used, such as Precedence, Message Type and SIC code information (see RFC 6477 “Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail" ). This additional header use increases the importance of providing security for message headers.

Fortunately, S/MIME specifies how to sign and encrypt message headers. Essentially, the approach is to wrap the headers in MIME, and then have a minimal outer message header to ensure protocol compliance. This approach is used in some military deployments, such as Australian Defence Force.

Use of S/MIME header signing and encryption has poor interoperability with email clients that are not aware of this mechanism, as they will display such messages in a manner that is not particularly useful. When header signing is deployed for end to end security, it is important to ensure that it is supported by all email clients used. Header signing can generally be used safely for server to server security.

Where gateways modify headers, header signing needs to be taken into account; If the header has been signed, the gateway will need to strip and re-sign after header changes have been made. If changes are made to a header and the body part is signed (but not the header) this may still cause issues if the header modifications cause the new From: of the message to conflict with the signature.

Security Labels

Use of security labels, such as “UK SECRET RELEASABLE TO DEU/UK/USA”, is important for military and other high security messaging and not generally available in commercial email clients. The ESS specifications standardize a security label format which is used with S/MIME ESS and with STANAG 4406 military messaging. The ESS structure is designed to work with security label frameworks such as US SDN.801c and NATO AC/322-D (2004) 0029 (INV). Further information on Security Labels is provided in the Isode whitepaper [Access Control using Security Labels & Security Clearance].

ESS handles security labels as S/MIME attributes. A key benefit of this is that it enables a security label to be "bound" to the message. This binding is considered a desirable security characteristic, as it locks the label to the message and securely identifies exactly what has been labelled. 

Multiple Signatures

Commercial implementations of S/MIME generally configure an email user with a private key, and then enable messages to be signed by that user as the email sender on message submission. This is generally a useful way to work, as the receiver of a message will typically expect a message to be signed by the person that sent it.

For military messaging, signature from the user creating the message is often not appropriate. Formal military messages use a process known as “draft and release”. Messages are created by a "drafter" and then authorized by a "releasing officer". When S/MIME is used, the important external signature is from the releasing officer. This address would be represented in an “MMHS-Authorizing-Users:” field. Use of this field and associated S/MIME signature is described in "Draft and Release using Internet Email".

In addition, CMS and S/MIME support multiple message signatures. There are several approaches that CMS supports for signing messages. An important distinction between two types of signature is:

• Having multiple independent signatures of the same message.
• Having a counter-signature, where a signature is signed. This enables a signer to validate an existing signature.

Multiple signatures may be useful in situations where a recipient is technically not able to verify one signature. In military and high security environments, multiple signatures can be helpful to deal with workflow and audit requirements. In the draft and release process described above, it may be desirable to have the drafter sign the message and then have the release officer counter-sign it. In more complex situations, signatures from message reviewers and from multiple authorization points may be helpful to expose correct process to the message recipient and to create a secure audit trail.

Triple Wrap

CMS defines a number of formats for handling secure data, two of which are of particular importance for S/MIME. The “enveloped data” format provides encryption and the "signed data" format provides signing. These formats can be used in multiple layers by S/MIME. Commercial email will typically provide:

• Signing using "signed data" (which may be encoded as S/MIME opaque or clear signed)
• Encryption only, using "enveloped data" (which is always encoded S/MIME opaque)
• Encryption and signing, using "signed data" inside "enveloped data"

ESS defines a third option for using CMS layers in S/MIME, called "Triple Wrap".

Triple wrap is exactly what it says. There are three layers of CMS used: the middle layer uses CMS enveloped data to provide encryption, and then there are signature layers both inside and outside the encryption (there may also be a security label associated with one or both of these signature layers).

The inner signature will be needed when the signature or security label is sensitive, and so needs to be protected with encryption. The inner signature layer is the primary place when a message is signed.

The outer signature is used where there is a need to sign the encrypted layer or to carry secure attributes outside the encryption. This will be important where message signature or security label will be checked in transit, by entities that may not have a private key needed to decrypt the message. The outer security label and signature may be different to the inner one. This structure may also be used for a gateway which performs re-encryption, but the inner signature is carried end to end. This layering is particularly important for secure mailing lists, as it enables the message originators signature to be carried end to end, and the mailing list agent can sign the message after it has added the ability for list members to decrypt the message.

ESS triple wrap can also help to protect against surreptitious forwarding as described “Defective Sign Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML”. Header signing is also helpful to protect against surreptitious forwarding.

Gateways and Cross Domain

The standard S/MIME model, implemented by commercial S/MIME implementations, is fully end to end. A message is signed and encrypted by the sender, and verified and decrypted by the recipient. This model has significant problems when operating on cross domain military environments (e.g., between UK and US). Constraints that may be imposed at the boundary:

1. Message content will need to be checked for policy and virus. To achieve this, the gateway will need to decrypt the message.
2. Although verification of digital signatures can be made to work cross domain, by use of PKI cross-certification, this will often not be done on national networks. This means that cross domain signature verification will not work in such situations.
3. The public keys of users on a national network will typically not be shared cross domain. This means that it will not be possible for a sender to encrypt a message for a cross domain recipient.
4. Messages may need to be modified at the boundary. In particular, security labels may need to be modified from remote to local policy. See [Security Label Capabilities in M-Switch] .

A solution to address these constraints by decrypted messages at the domain boundary is shown below.

In cross domain configurations the end to end security model does not work. End users will need to encrypt the message for the boundary gateway. At the boundary, encryption and message signatures will typically be stripped and then new signatures and encryption added on the destination side. This can be achieved by Isode’s Encryption add-on for M-Switch products.

To use this sort of gateway with standard email clients, the messaging client will typically need to “cc: the gateway” in order to provide the gateway with the information needed to decrypt the message. This is unnatural and awkward for the end user. It would be preferable to provide a mechanism for this to happen which enables a UA to determine if a decrypting gateway is being used and to provide the appropriate keys transparently, so that the user does not need to take special action.

Server to Server Encryption

Although S/MIME is designed to operate end to end, there are situations where the critical protection needed is over a connection between a pair of MTAs or between a sequence of MTAs. This can be provided by M-Switch Encryption as shown below.

This architecture has two advantages over the end to end approach:

1. If there is no requirement for client to gateway encryption, this leads to a simpler approach than the cross domain architecture described above.
2. It enables some measure of encryption support for clients (in particular Web clients) that do not support S/MIME encryption.

Conclusions

In conclusion, S/MIME is the only viable option to provide security for SMTP based military messaging service. Although existing S/MIME standards provide the majority of what is needed for such a service, there are four areas where work is needed:

1. Clarification on the best approach for secure read receipts, and delivery reports (DSNs).
2. To standardize guidelines for handling the outer header when message header signature and encryption is used. Isode plan to work on this.
3. S/MIME is specified in terms of client signing. To support server to server encryption, DSN signing and cross domain operations with gateway decryption, it is necessary to have message server signing. Isode is leading work to standardize this in “MSA-to-MDA S/MIME signing & encryption”.
4. Standardization of a mechanism to enable clients to use a decrypting gateway transparently.