Server to Server Operation
The simplest way to deploy M-Switch Encryption is in a pair-wise configuration, where messages are encrypted by one M-Switch Encryption Server and then decrypted by its peer. This provides a setup where messages between a pair of MTAs, possibly with other MTAs in between that switch the encrypted messages, support end points which do not encrypt messages.
This configuration may run between two M-Switch Encryption servers, or between M-Switch Encryption and another server supporting the same encryption mechanisms.
There are a number of situations where this approach may be reasonable. The first is when two organizations run messaging locally without use of encryption, which may be for technical reasons (e.g., components that do not support encryption) or for policy reasons (e.g., to not encrypt data in a secure local environment). M-Switch Encryption enables messages to be encrypted when they are transferred between the organizations, thus providing protection.
M-Switch Encryption can be used to support email clients that do not provide encryption. For example Webmail clients rarely provide message encryption support. Typically, local protection such as use of TLS can provide security to and from the client, and then M-Switch Encryption can provide server to server protection.
Server to Client Operation
M-Switch Encryption can also be used in an asymmetrical configuration as shown above. As with the symmetric configuration, one side of the system is unencrypted. However, on the encrypted side, encryption is handled at the client level. This might be used to support a mix of organizations where some use client encryption and others do not.
When it receives an encrypted message from a client, M-Switch Encryption will need to decrypt it. An encrypted message will be encrypted for a number of recipients, using the public key of that recipient. This means that the sender needs to encrypt the message for the specific instance of M-Switch Encryption. This is often achieved by the user “cc’ing the gateway” which is a practical although not entirely desirable approach.
When encrypting a message for an end client, M-Switch will need the public key for that user. It obtain this key by lookup in a local database based on the recipient’s address. This database can be manually populated or automatically by caching of a certificate, from when that user has sent a signed message.
Supported Protocols and Options
M-Switch Encryption supports two types of message encryption, both which are based on use of the Cryptographic Message Syntax (CMS) open standard specified in RFC 5652. The first S/MIME encryption (RFC 5751) for use with SMTP based messaging (M-Switch SMTP). This uses CMS enveloped data, which is the encryption approach used in widely deployed S/MIME clients.
The second type is STANAG 4406 encryption for use with STANAG 4406 military messaging (M-Switch X.400). This uses a technique called “triple wrap” where there are three layers:
- An inner CMS layer which has message signatures and security labels.
- An enveloped data CMS layer which provides the encryption.
- An outer CMS layer which has message signatures and security labels.
Signature capabilities are provided in the base M-Switch products. M-Switch Encryption adds the encryption layer. Where triple wrap is used, M-Switch encryption can add and remove all three layers. It can also add encryption only (no signature layers) and can add encryption and signature layers to a signed message.
Message encryption and decryption is configured in an M-Switch shaper channel with control by content subtype, so that it will be possible to encrypt all messages, or to encrypt messages on a selective basis. Decryption is always performed if a suitable private key is available. However, extraction of the contents (i.e. elimination of the encryption layer) is dependent on shaper channel configuration.
M-Switch Encryption supports the following CMS Capabilities and Algorithms:
- Key transport
- Key Agreement
Content Encryption Algorithms
Key Transport Algorithms
- RSA encryption
Key Agreement Algorithms
- Ephemeral-Static Diffie-Hellman
- Elliptic Curve Diffie-Hellman
Key Wrap Algorithms
- AES-128 Key Wrap
M-Switch Encryption is subject to UK Export Control, dependent on the country of end use. Use in the European Union does not require an export license. Use in US, Canada, Australia, New Zealand, Japan, Switzerland and Norway is permitted under a standard export license. Use in all other countries requires an export license. Isode does not anticipate problems in obtaining an export license for reasonable use of M-Switch Encryption.
- STANAG 4406, Edition 2. "Military Message Handling System", March 2005
- Annexe B: “Interoperability of Secure MMHS”
- STANAG 4631 “PROFILE FOR THE USE OF THE CRYPTOGRAPHIC MESSAGE SYNTAX (CMS) AND ENHANCED SECURITY SERVICES (ESS) FOR S/MIME”
- FIPS PUB 140-2: Security Requirements for Cryptographic Modules". NIST. July 2007
- RFC 2631 Diffie-Hellman Key Agreement Method; E. Rescorla; June 1999
- RFC 3217 Triple-DES and RC2 Key Wrapping; R. Housley; December 2001
- RFC 3370 Cryptographic Message Syntax (CMS) Algorithms; R. Housley; August 2002
- RFC 3394 Advanced Encryption Standard (AES) Key Wrap Algorithm; J.Schaad, R. Housley; September 2002
- RFC 3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS); J. Schadd; July 2003
- RFC 3854 Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME); P. Hoffman, C. Bonatti, A. Eggen; July 2004
- RFC 3855 Transporting Secure/Multipurpose Internet Mail Extensions
(S/MIME) Objects in X.400; P. Hoffman, C. Bonatti; July 2004
- RFC 5652 Cryptographic Message Syntax (CMS), R. Housley, September 2009
- RFC 5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification, B. Ramsdell, January 2010
- RFC 5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS); S. Turner, D. Brown; January 2010