"E-mail Encryption: Protecting Data in Transit"

If you receive errors when attempting to view this white paper, please install the latest version of Adobe Reader.

"SECUDE Secure Mail enables e-mails to be sent securely across open networks. Data confidentiality is ensured through the use of encryption. "
Source : SECUDE International AG

Resources Related to E-mail Encryption: Protecting Data in Transit:

• E-mail Encryption (Wikipedia)

E-mail Encryption: Protecting Data in Transit

Executive Summary

Secure Mail enables e-mails to be sent securely across open networks. Data confidentiality is ensured through the use of encryption. Digital signatures are used to demonstrate the authenticity and the integrity of an e-mail message. Secure Mail is a plug-in that integrates seamlessly into Microsoft Outlook. The main functions of Secure Mail are provided in the toolbar or the menu. In addition, it is possible to pre-assign various setup options before the software is rolled out. These options can be locked so that the user can no longer change the default settings. This white paper describes the main properties of Secure Mail and provides an overview of the large number of possible configurations the product offers.

Table of Content

• 1 Introduction
  It would be impossible to imagine the world of business today without electronic communication via e-mail. Yet, messages are often sent unprotected across open networks with nothing to guarantee the confidentiality, authenticity, and integrity of a message. Nevertheless, these aspects are of vital importance for the effective and safe use of e-mail in electronic business. Secure Mail enables e-mails to be sent securely across open networks. Data confidentiality is ensured through the use of encryption. Digital signatures are used to demonstrate the authenticity and the integrity of an e-mail message. Secure Mail is a plug-in that integrates seamlessly into Microsoft Outlook. The main functions of Secure Mail are provided in the toolbar or the menu. In addition, it is possible to pre-assign various setup options before the software is rolled out. These options can be locked so that the user can no longer change the default settings. This white paper describes the main properties of Secure Mail and provides an overview of the large number of possible configurations the product offers. 4
• 2. Functions
  • 2.1. Sending messages
  • 2.2. E-mail splitting
  • 2.3. Expertise
  • 2.4. Connection of directory services
  • 2.5. Certificate verification
  • 2.6. Certificate manager
  • 2.7. Settings
  • 2.8. Replying to and forwarding e-mails
• 3. E-mail standards
  • 3.1. S/MIME
  • 3.2. PGP
• 4. PGP functionality
  • 4.1. Restrictions
• 5. PGP-specific settings
  • 5.1. Setting standard methods
  • 5.2. Choosing the format
  • 5.2.1. Plain text format
  • 5.2.2. HTML format
  • 5.2.3. Rich text format
• 6. Import and export of certificates
  • 6.1.1. Importing public PGP keys
  • 6.1.2. Exporting public PGP keys
• 7. Decoding and verifying PGP messages
  • 7.1. PGP e-mail types supported
  • 7.2. Expertise for PGP messages
    • 7.2.1. The detailed expertise
• 8. Sending and forwarding
  • 8.1. Supported formats
• 9. Store provider 12
  • 9.1. Security problem in the Microsoft Exchange transport mode
  • 9.2. The solution: SECUDE store provider
• 10. Overview of architecture
  • 10.1. Smartcard bindings
• 11. Technical prerequisites
  • 11.1. System requirements
  • 11.2. Software requirements
  • 11.3. Supported Hardware
  • 11.4. Supported signature algorithms
    • 11.4.1. S/MIME
    • 11.4.2. OpenPGP
  • 11.5. Supported encryption algorithms
    • 11.5.1. S/MIME
    • 11.5.2. OpenPGP
• 12. Abbreviations
• Abbreviation
• Description
• About SECUDE

1. Introduction

It would be impossible to imagine the world of business today without electronic communication via e-mail. Yet, messages are often sent unprotected across open networks with nothing to guarantee the confidentiality, authenticity, and integrity of a message. Nevertheless, these aspects are of vital importance for the effective and safe use of e-mail in electronic business. Secure Mail enables e-mails to be sent securely across open networks. Data confidentiality is ensured through the use of encryption. Digital signatures are used to demonstrate the authenticity and the integrity of an e-mail message. Secure Mail is a plug-in that integrates seamlessly into Microsoft Outlook. The main functions of Secure Mail are provided in the toolbar or the menu. In addition, it is possible to pre-assign various setup options before the software is rolled out. These options can be locked so that the user can no longer change the default settings. This white paper describes the main properties of Secure Mail and provides an overview of the large number of possible configurations the product offers.

2. Functions

2.1. Sending messages

With Secure Mail, e-mail messages are created and sent as usual. Encryption and signature can be activated simply by clicking the buttons made available in the toolbar.

Microsoft Outlook ordinarily lets you adjust a message’s importance and level of confidentiality with options accessed by clicking the “Options…” button. If this information conflicts with the settings for encryption or signature provided by Secure Mail, a warning is issued when the message is being sent

In order to send an encrypted message, you need the recipient’s public key. This is generally available as a certificate if a signed e-mail has already been received from this person. If this is not the case, you can search for the recipient’s certificate using LDAP.

Where possible, Secure Mail assigns the certificate to the recipient automatically. If the assignment is not clear or if no certificate can be assigned to the recipient, the user is asked to select the recipient certificate when sending the e-mail.

The standard used by the recipient to send secure e-mail messages – S/MIME or PGP – is selected automatically on the basis of certificate and recipient properties. In the event of ambiguity, the default format is used.

If necessary, the e-mail message may be split before sending to support two formats in a single send process.

2.2. E-mail splitting

Where possible, Secure Mail sends new e-mail messages in such a way that the selected level of security is retained with all its functions and convenience.

1. Recipients with an S/MIME certificate receive only S/MIME e-mails.
2. Recipients with a PGP key receive only PGP e-mails.
3. Each recipient sees all other recipients apart from the Bcc: group.
4. All sent messages are also encrypted for the sender.
5. Identifying the Bcc: group on the basis of a cryptographic format analysis cannot be allowed.

One, two, or even more separate e-mails are therefore sent, depending on the recipient’s email functionality.
Example:

• Smith and Jones have S/MIME certificates
• Brown and Black have PGP keys
• “Sender” has a S/MIME certificate
• The standard format set is S/MIME

“Sender” sends an encrypted e-mail to the recipients:

2.3. Expertise

When a signed e-mail message is opened, secure mail verifies the signature. If the verification is unsuccessful, the “Expertise” dialog box appears to inform the user of this. Verification is unsuccessful if e-mail messages cannot be decrypted or have an invalid signature.

The “Expertise” dialog box can also be accessed for viewing at any time via the menu.

Clicking on “Details” will display detailed information on the result of the verification.

The “Expertise” dialog box displays whether the e-mail is S/MIME- or PGP-encoded.

2.4. Connection of directory services

To be able to encrypt e-mail for a recipient, you need the recipient’s certificate. If this is not yet stored in the local directory, the certificate is searched for using LDAP. If the feature specifying validation against revocation lists has been activated for the certificate verification, secure mail automatically searches for the required revocation lists using LDAP.

Several LDAP directory services can be configured in secure mail. The sequence for the search in the directory services can also be specified. The search for certificates is currently limited to S/MIME certificates.

If the computer is in a Windows 2000/2003/2007 domain with Active Directory, direct communication with the ADS or the global catalogue is possible; in that case the Windows logon is automatically used for authentication.

2.5. Certificate verification

Apart from the mathematical accuracy of the certificate and the certificate chain, a complete verification also involves a request regarding the status of each individual certificate in the certificate chain. Secure Mail provides two options for determining the status of the certificate.

• LDAP can be used to check revocation lists. These contain the serial numbers of revoked certificates.
• If the trust center allows the certificate status to be requested online, Secure Mail enables you to use OCSP in determining whether or not a certificate has been revoked.

2.6. Certificate manager

The certificate manager is used to manage the recipients’ certificates. It allows S/MIME certificates to be manually searched for in a supported directory (LDAP, ADS, or HTTP). Certificates found in a directory can be copied into the local certificate cache of Secure Mail. This means they are available even if the directory service cannot be accessed. Certificates that are no longer needed can be deleted.

2.7. Settings

The “Settings” dialog box allows users to change the configuration of Secure Mail.

This section provides examples of the most important settings. For outgoing e-mails, you can specify whether PGP or S/MIME is to be used as the standard encoding format. This standard is used when no decision has been made as to whether PGP or S/MIME should be used for the recipient’s address.

In addition, a choice is offered between different S/MIME e-mail types and cryptographic algorithms.

The dialog box also allows you to set the PIN policy for security tokens. You can stipulate entry of a PIN either each time the private key is used or only once per session. In the latter case, single sign-on  to other SECUDE applications is an additional option. PIN timeout can also be set; if no operation is carried out using the private key during a specified amount of time, the PIN will be requested again for the next operation. Configuration for the LDAP client and the OCSP client is also defined in the “Settings” dialog boxes.

The settings options can be locked to avoid user customization. In this way, a company can enforce a specific e-mail security policy. The feature making e-mails readable by group simplifies collaborative work. If one designated member of a group receives an encrypted e-mail, it can be very easily made available to all group members. The e-mail message does not have to be stored in plain text; it can continue to be managed in encrypted form.

2.8. Replying to and forwarding e-mails

Two important aspects of e-mail security are replying to and forwarding of encrypted or signed e-mails. In both cases, the following applies: if the security settings of the original email differ from the proprietary settings, the high-order settings are automatically used. If, for example, the proprietary settings stipulate that an e-mail message must be encrypted but not signed, and the original e-mail is signed but not encrypted, the reply or the forwarded e-mail is sent both encrypted and signed.

The following alternatives are possible:

Forwarding of signed messages:

• The original signature is retained if the message is forwarded as an attachment; otherwise a warning is issued and the signature may also be removed.
• Settings for forwarded message: signed

Forwarding of encrypted messages:

• The original encryption is removed.
• Setting for forwarded message: encrypted for the new recipient. If the message is forwarded as an attachment, the attachment is not encrypted again.

Forwarding of encrypted and signed messages:

• The original signature is retained if the message is forwarded as an attachment; otherwise a warning is issued and the signature may be removed.
• The original encryption is removed.
• Settings for forwarded message: signed and encrypted for the new recipient. If the message is forwarded as an attachment, the attachment is not encrypted again.

Replying to signed messages:

• Original signature is removed (unless the e-mail message is forwarded as an attachment).
• Settings for reply: signed

Replying to encrypted messages:

• The original encryption is removed.
• Settings for reply: encrypted for the recipient. If the message is forwarded as an attachment, the attachment is not encrypted again.

Replying to encrypted and signed messages:

• Original signature is removed (unless the e-mail message is forwarded as an attachment).
• The original encryption is removed.
• Settings for reply: signed and encrypted for the recipient. If the message is forwarded as an attachment, the attachment is not encrypted again.

3. E-mail standards

Secure Mail supports different e-mail security standards.

3.1. S/MIME

The S/MIMEv2 standard is used all over the world. In the encryption or the signature, the message is treated as a unit. This also includes any existing attachments. Secure Mail allows you to choose between different message formats: Multipart Signed (“clear”), Signed Data (“opaque”), and Signed and Enveloped. Multipart Signed messages can be read by each MIME e-mail client. Verification is only possible with S/MIME-enabled clients, however. Messages in the Signed Data and Signed and Enveloped formats can only be processed by S/MIME-enabled clients.

3.2. PGP

Apart from S/MIME, secure mail also supports OpenPGP. The keys used for S/MIME are used to create signed and encrypted messages that are compatible with OpenPGP. The exact functional scope of the PGP module is described in a separate section.

4. PGP functionality

Two incompatible standards exist for secure e-mail: S/MIME and PGP. Secure Mail supports both formats for the secure sending of e-mail.

4.1. Restrictions

Secure Mail is designed for customers who have opted for S/MIME as their standard and need PGP to communicate with a number of partners. For this reason, we have assumed that an X.509 PKI has already been or can be rolled out. This gives rise to the following restrictions for the existing version:

• Currently no import of private PGP keys is available (see Section 7 of this paper, "Import and Export of Certificates").
• When public PGP keys are imported, the signatures are deleted; for this reason each imported certificate must be explicitly trusted.

The X-509 certificates from the smartcard or the software token are used as the basis for the OpenPGP. The same profiles and keys can thus be used transparently for both standards, meaning that users do not have to actively choose between S/MIME and PGP.

5. PGP-specific settings

5.1. Setting standard methods

As explained earlier, a standard method (S/MIME or PGP) can be specified for outgoing emails. This method is used when the recipient was not assigned a fixed standard. For S/MIME and OpenPGP, the encryption algorithms are freely selectable. For a complete list of algorithms, see the chapter of this paper entitled Technical requirements.

5.2. Choosing the format

Microsoft Outlook allows users to choose between three text formats for sending or replying to messages. Not all are fully supported at present. More information on the individual formats is provided below.

5.2.1. Plain text format

This format is the simplest and is fully supported by the SECUDE OpenPGP engine.

5.2.2. HTML format

The SECUDE OpenPGP engine also supports simple HTML messages. Embedded objects, such as images or graphics, are encrypted and sent in a form that is compatible with PGP Desktop 8.0. However, since no standard method for this exists in the PGP world, interoperability problems with other PGP clients may arise. For this reason, the unformatted text of the message is also sent as plain text (i.e., in a format compatible with the majority of PGP clients), so that at least the text message can be read by each e-mail client.

5.2.3. Rich text format

Rich text format is not yet fully supported. The text and the attachments can be sent as well as decoded and verified; however, some of the formatting may be lost in the process. Special formats and OLE objects or similar elements cannot be sent or read. As for HTML, messages are encrypted and sent in a format that is compatible with PGP Desktop 8.0. However, since there is no standard method for this in the PGP world, interoperability problems with other PGP clients may arise. Here, too, the unformatted text of the message is also sent as a plain text message so that at least the text message can be read by every e-mail client. Caution: Microsoft Word as e-mail editor is currently not supported!

6. Import and export of certificates

Each standard method has its own certificate format. S/MIME uses X.509, and OpenPGP uses its own PGP format. These are incompatible; they can be converted from one to the other, but in doing so the signatures are lost. To ensure interoperability between the two standards, public PGP keys are converted into X.509 certificates. The internal presentation of public keys in secure mail is always an X.509 certificate. Conversely, public PGP keys can be exported from the proprietary X.509 certificates available in the PSE. The export or import of secret PGP keys is not yet supported. When encrypted PGP messages are sent to recipients whose certificate is not in the local directory, the required public  keys are obtained from the Microsoft Outlook address book. If you wish to communicate with an unknown participant who does not have a certificate in the public directory, PGP certificates can also be exported or imported manually.

6.1.1. Importing public PGP keys

To be able to encrypt an e-mail message for a recipient or to verify an incoming message, the communication partner’s public key(s) is/are needed. Secure Mail allows you to import public PGP keys (extension: *.asc, *.pkr, or *.pgp). During the import, an X.509v3 certificate is generated for PGP keys version 2.x with the extension KeyUsage = Encryption and Signature. With the certificate, e-mail may then be encrypted and verified. From version 5.0 on, PGP key files have two public keys. One is used for verification, while the other is used for encryption for the recipient. Two X.509 certificates are therefore generated with different key usage. The X.509 certificate belonging to the sub-key is given the extension KeyUsage = Signature, while the X.509 certificate belonging to the public key is given the extension KeyUsage = Encryption. The signature field of the X.509 certificates generated from the PGP keys remains empty. The certificates are then stored in the local directory. Since the key ID is an i portant feature of a PGP key, it is also retained after the import into an X.509 certificate. When the certificate is displayed, the key ID is calculated once more. The X.509 standard does not include certificates with an indefinite validity period; however, this may be the case for PGP keys. For this reason, when a public PGP key with an indefinite validity is imported, the “valid until” value of the X.509 certificate is set to the date January 1, 2038. The automatic certificate verification is now unable to check the validity of these certificates because they are not signed. They must later be manually flagged as trusted.

6.1.2. Exporting public PGP keys

The proprietary X.509 certificate can be converted into a self-signed PGP key and exported.

7. Decoding and verifying PGP messages

To ensure interoperability with the majority of PGP-enabled e-mail clients, Secure Mail understands the most common algorithms and formats from the OpenPGP standard (RFC 2440).

7.1. PGP e-mail types supported

• Old text/plain PGP format in accordance with RFC 1991
• Detached signatures
• Embedded messages
• HTML (compatible with PGP Desktop 8.0)
• Rich text format (compatible with PGP Desktop 8.0)
• MDC (Modification Detection Code) by GnuPG

7.2. Expertise for PGP messages

The result of the verification or decoding of a PGP message is the first thing to be displayed in a so-called short expertise within the “Expertise” dialog box, and can be examined in detail by clicking the “Details” button in the dialog box. Normally, the “Expertise” dialog box is only displayed if a message cannot be decoded or verified. This behavior can be changed through customization, however.

7.2.1. The detailed expertise

The detailed expertise can be accessed for viewing from the short expertise by clicking the “Details” button in the “Expertise” dialog box. The detailed PGP expertise differs from an S/MIME expertise in a number of ways, since in the PGP format each part of a message can be encrypted/signed with a  different certificate (or not at all in the case of some PGP clients). For this reason, all parts must be verified separately and displayed to the user. The recipient in question, the recipient’s certificates, and the algorithms used are all displayed for the encrypted parts of a message.

The sender and the sender’s certificates or key IDs are displayed for the signed parts of a message. In addition, a check against a revocation list can be performed.

8. Sending and forwarding

When a new message is sent, the standard method (selected in the settings) is normally used. The method used by the sender is generally used for replying to or forwarding a message. The method can be changed for the message in question, however. An exception is only made if the recipients’ addresses for PGP and S/MIME have been configured to a specific method on a domain basis through customization. This configuration then takes precedence over all other settings.

8.1. Supported formats

• Old text/plain PGP format in accordance with RFC 1991
• Detached signatures
• Embedded message
• HTML (compatible with PGP Desktop 8.0)
• Rich text format (compatible with PGP Desktop 8.0 but with some loss of formatting possible)

9. Store provider

9.1. Security problem in the Microsoft Exchange transport mode

When Microsoft Outlook runs in the unsecured Exchange Transport mode (Microsoft Outlook and Exchange and up already support a more secure transport mode), the content of an e-mail message in plain text is exchanged between Microsoft Outlook and the Exchange Server when the message is being edited. It goes without saying that this is not desirable; after all, the content is considered confidential. Using an ordinary network sniffer, a hacker would have little difficulty reconstructing the e-mail before it was sent encrypted.

9.2. The solution: SECUDE store provider

Secure Mail has its own store provider to solve this security problem. This oversees all communication between the Microsoft Outlook Client and the Exchange Server, and ensures that information classified as confidential is always sent encrypted.

10. Overview of architecture

SECUDE secure folder integrates seamlessly into Microsoft Outlook as an Office add-in that directly communicates with the SECUDE library.

10.1. Smartcard bindings

Secure Mail, like all other Office Security Suite components, attempts to automatically detect any inserted smartcard as long as the smartcard drive has been properly configured. For this reason, we ship our software with a well-tended identification list of available smartcards that can be easily extended.

11. Technical prerequisites

11.1. System requirements

• Min. PC 486 or Pentium (recommended: at least 16 MB available RAM)
• Microsoft® Windows® 2000/XP/Vista

11.2. Software requirements

• Microsoft® Outlook® 2000/XP/2003/2007
• Microsoft® Exchange Server 2000/2003/2007
• Microsoft Internet Explorer 5.5 or higher

11.3. Supported Hardware

• PC/SC Smart card Reader
• CT API (PIN Pad Terminals)
• SECUDE TrustManager Smart cards
• Signaturgesetzkonforme Smart cards
  • Datev
  • TeleSec
  • Signtrust
• TCOS Smartcards
  • TCOS 2.0 MIN
  • TIK0053
  • NetKey
  • NetKey2000
  • NetKeyE4 Triple Key
  • NetKey 3.
• PKCS#11 Smartcards
  • StarCos
  • CardOS
  • AET SafeSign Middleware (G&D)
  • Siemens HiPath SIcurity
  • Aladdin
  • RSA
  • Gemplus
  • Microsoft Cryptographic API (CAPI)-compatible Smartcards and Soft-token

11.4. Supported signature algorithms

11.4.1. S/MIME

• RSA/DSA + SHA-1
• RSA + RIPEMD-160
• RSA + MD5

11.4.2. OpenPGP

• SHA-256
• SHA-384
• SHA-512
• SHA-1
• RIPEMD-
• MD5

11.5. Supported encryption algorithms

11.5.1. S/MIME

• DES-EDE3-CBC
• DES3
• DES
• RC2 (40-, 64-, 128-bit)
• RC4
• AES-ECB (128-, 192-, 256-bit)
• AES-CBC (128-, 192-, 256-bit)
• AES-OFB (128-, 192-, 256-bit)
• AES-CFB (128-, 192-, 256-bit)

11.5.2. OpenPGP

• DES-EDE3-CBC
• AES-CFB (128-, 192-, 256-bit)
• TWOFISH-CFB (256-bit)
• BLOWFISH-CFB (128-bit)
• CAST-CFB (128-bit)

About SECUDE

SECUDE offers comprehensive SAP Security solutions to business and government partners around the world. With our Identity & Access Management and System Security Assessment technologies and services, we effectively protect enterprise data across the IT landscape

SECUDE is a member of SECUDE AG and was founded in 1996 out of a partnership between SAP AG and Fraunhofer Institute in Darmstadt, Germany. Headquartered in Zurich, Switzerland, we have a worldwide partner and customer base with offices in North America, Europe, the Middle East, and Asia.

For further information, please consult
www.secude-ag.com
SECUDE AG
Bergegg 6376 Emmetten,
NW Switzerland
Tel : +41 (0) 44 575 19 10
info@secude.com