Secure Messaging

X.400 Message Switch

M-Switch X.400 is a high-performance, versatile Message Transfer Agent (MTA). It can be deployed either to support local users or as a gateway, switching messages between other MTAs. M-Switch X.400 is widely used in Civil Aviation, EDI and Military environments.

M-Switch Configuration

The M-Switch Profiler enables messages to be delivered to recipients based on message content, a capability often required as part of a military messaging solution. The M-Switch Profiler is a high functionality profiler which addresses NATO and other high-end profiler requirement sets.

The M-Switch Profiler is an M-Switch componant which takes an input message and distributes the message to new recipients.

  • A message to a profiled address is delivered to the profiler. This means that any positive delivery reports are generated
  • The profiler determines new recipients for the message using information in the message, such as SICs.
  • A new message is generated and submitted to the MTA, with the new recipients as the envelope recipients.

Message Selection & Processing

Messages are selected for processing based on message attributes including SICs, SIC pattern, originator, Message Type and associated parameters (e.g., Exercise), message priority, message security label/classification, and message instructions. Messages are then processed based on keywords in the message subject and content.

New recipients for the processed message may be ‘action’ or ‘information’ recipients. If the Profiler determines that the original recipient of the message was an ‘information’ recipient, then all recipients of the processed message will be ‘information’ recipients.

Profiler incorporates switchable plans (e.g. War and Peace) as well as different rules for message handling at different times of day. An Operator Web GUI (shown below) is available for manual processing of messages which cannot be automatically profiled.

profiler-distribution

Message Protocol Support

The M-Switch Profiler is multi-protocol, operating directly on the three standard military messaging protocols:

The M-Switch Encryption add-on enables message encryption/decryption using S/MIME for SMTP messages and STANAG 4406 Encryption for X.400 messages.

Configurations

M-Switch Encryption is an add-on which enables message encryption and decryption capabilities (using S/MIME for SMTP messages and STANAG 4406 Encryption for X.400 messages) for the following products:

Server to Server Operation

The simplest way to deploy M-Switch servers with the Encryption add-on is in a pair-wise configuration, where messages are encrypted by one 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.

m-switch-encryption

There are a number of situations where this approach may be reasonable, such as:

  • 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.
  • Support for 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 servers with the Encryption add-on can also be used in an asymmetrical configuration as shown below. 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.

m-switch-encryption-2

When it receives an encrypted message from a client, the M-Switch Encryption add-on 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 the Encryption equipped server. This is often achieved by the user copying the gateway, which is a practical although not entirely desirable approach.

When encrypting a message for an end client, the M-Switch server will need the public key for that user. It obtains 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 is S/MIME encryption (RFC 5751) for use with SMTP based messaging. 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. This uses a technique called “triple wrap” where there are three layers:

  1. An inner CMS layer which has message signatures and security labels.
  2. An enveloped data CMS layer which provides the encryption.
  3. An outer CMS layer which has message signatures and security labels.

Signature capabilities are provided in all products in the M-Switch family, 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.

Configuration options allow for the encryption of all messages, or the encryption of messages on a selective basis. Decryption is always performed if a suitable private key is available. M-Switch Encryption supports the following CMS Capabilities and Algorithms:

Key Encryption Key Transport
Key Agreement
Content Encryption Algorithms AES-128-CBC
Key Transport Algorithms RSA Encryption
Key Agreement Algorithms Ephemeral Static Diffie-Hellman
Elliptic Curve Diffie-Hellman
Key Wrap Algorithms AES-128 Key Wrap

Open Standards

The M-Switch Encryption add-on complys with the following Open Standards:

STANAG 4406 Edition 2: Annex B Military Message Handling System, Annex B: Interoperability of Secure MMHS, March 2005
STANAG 4631 Profile for the use of 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

The M-Switch ACP127 add-on enables message conversion to/from ACP127, SMTP and STANAG 4406 and provides full support for the ACP127 protocol and for the related ACP126, ACP128, JANAP128 and DOI103S protocols.

Configurations

Two add-ons, providing ACP127 Core capabilities and ACP127 Broadcast, as set out in BRASS (Broadcast Ship to Shore), are available for the following products:

Deployment Modes

When added to the appropriate M-Switch product, the ACP127 add-on can be configured to address various deployment modes, which can be used in isolation or in combination.

acp-127

ACP127 End User System

Added to M-Switch SMTP, the add-on can be used to support end users using Isode’s Harrier (M-Switch), an SMTP/IMAP military messaging client which includes an ACP127 mode. Harrier provides all of the capabilities needed in ACP127 including user addresses in ACP127 format (Routing Indicator (RI) and Plain Language Address (PLA)), as well as a choice of IA5 and ATA2 character sets.

ACP127 Relay

Added to an M-Switch gateway, the add-on can be configured as an ACP127 relay. Routing between ACP127 peers is configured use Routing Indicator (RI) prefix. This allows for completely flexible routing, with the prefix approach allowing for succinct specification of routing in common relay setups. Protocol conversion (e.g., between ACP127 and ACP128) can be performed.

BRASS/BRE1TA

M-Switch may be used in support of NATO BRASS (Broadcast and Ship to Shore) and BRE1TA (BRASS Enhancement 1 Technical Architecture) deployments. This capability includes RECAP Messages, OTAM (Off The Air Monitoring) and other elements important for these deployments. A detailed description is given in the whitepaper [Isode’s Solution for BRASS (Broadcast and Ship to Shore)].

Gateway to SMTP/STANAG 4406

Added to M-Switch SMTP (Gateway) the add-on enables message exchange between ACP127 and M-Switch SMTP, which supports extensions for military messaging as described in the whitepaper [Military Messaging (MMHS) over SMTP]. M-Switch X.400 (Gateway) with the M-Switch ACP127 add-on can be deployed as a gateway between ACP127 and STANAG 4406 (the NATO standard for organizational messaging), following the specifications set out in STANAG 4406 Annex D.

Capabilities

Message Transport

Support is provided for the three primary approaches used for connecting ACP127 systems; Serial Line, HF Radio and TCP.

ACP127 was initially designed for operation over serial lines to communicate with teletypes and operation directly over serial ports is still important for many deployments, including direct operation over HF Radio modems without use of STANAG 5066 ARQ. The following serial interfaces are supported:

  • Windows COM Port
  • Digiport TS Server Asynchronous serial hub

ACP127 is widely deployed over HF Radio using STANAG 5066, particularly in Naval environments. This is done using the Character-Oriented (COSS) protocol defined in Appendix F of STANAG 5066. COSS support is included in the M-Switch ACP127 channel which can be selected by configuring a circuit to use a STANAG 5066 server such as Isode’s Icon 5066.

Address Mapping

The preferred approach for address mapping between ACP127 and SMTP and/or STANAG 4406 is to have a directory entry for each user supported at the gateway. The directory entry will include:

  • ACP127 Plain Language Address (PLA).
  • ACP127 Routing Indicator (RI).
  • SMTP address and/or X.400 O/R Address.

Directory search can then be used to identify the entry and map between addresses at the gateway. A Directory entry is essential for any SMTP or X.400 user communicating with ACP127, as there is no mechanism to encode SMTP and X.400 addressing information in ACP127.

For ACP127 users communicating across the gateway, use of a mapping entry is recommended. This enables ACP127 users to have “clean” addresses for use in SMTP or STANAG 4406 systems.

Collation of Large Messages

ACP127 messages are small and do not have attachments. A typical M-Switch ACP127 configuration will use authorization to prevent messages with attachments or very large messages being sent over ACP127 (and an appropriate error message sent to the sender).

Some variants of ACP127 (e.g., DOI-103S) have a mechanism for splitting large messages into small messages, which M-Switch supports. M-Switch will also re-assemble such messages so that message splitting is transparent to SMTP and STANAG 4406 users.

In most situations, the will provide a reliable service for sending large messages, and use of service messages to request retransmission (based on channel sequence number) will ensure no message loss. In the event of a message being received with missing fragments and the missing fragments not arriving in response to a service message request, the message will be sent with clearly marked “gaps” at a timeout interval configurable according to message priority. For very high precedence, only minimal time can be waited for collation, so they will typically be sent as fragments without collation.

Security Labels and Access Control

ACP127 provides two security label mechanisms. A few basic labels are in the core ACP127 protocol and extended labels may be used. This enables security label based access control for inbound ACP127 messages and flexible security label mappings, for example to facilitate integration with ACP145 gateways.

ACP127 Service Messages & Reliability

ACP127 sends messages over a TCP connection or serial line. There is no protocol acknowledgement and there are no end to end delivery reports as in X.400 and SMTP.

ACP127 achieves reliability by sequentially numbering each message sent to a peer, which enables the receiver to detect if any messages are missing. ACP127 can send a special service message to request retransmission of any missing messages. M-Switch will detect missing ACP127 messages and request retransmission. The ACP127 sending channel holds all recently sent messages in a local database in order to facilitate this automatic transmission.

M-Switch also provides a configuration option to use ZIC/ZID service messages at intervals to automatically verify that a link is correctly working in both directions. ACP127 also defines special reliability options for FLASH messages which has special acknowledgement protocol. This can be selected for circuits where this is needed.

Management

Full GUI management for ACP127 is provided in the MConsole management GUI, including configuration of ACP127 peers and gateway mappings. General information on MConsole can be found on separate pages covering M-Switch configuration management and M-Switch operational management.

Specific capabilities relevant to ACP127 deployments of M-Switch, which include Error Handling (Operator Correction & ACP127 Repair) and Circuit Monitoring & Control, can be found on the M-Switch ACP127 Management page.

Open Standards

The M-Switch ACP127 Messaging add-on complies with the following Open Standards

STANAG 4406 Edition 2: Annex D Military Message Handling System, Annex D: MMHS APS/ACP127 Gateway, March 2005
ACP127 Communication Instructions – Tape Relay Procedures, November 1998
ACP126 Communications Instructions Teletypewriter (Teleprinter) Procedures, May 1989
ACP128 Allied Telecommunications Record System (ALTERS) Operating Procedures – ACP128(A), May 2005
DOI 103S Defense Operating Instructions DSSCS Messages
JANAP 128 AUTODIN Operating Procedures JANAP 128(I), March 1983
STANAG 5066 Edition 2 Profile for High Frequency (HF) Radio Data Communications: Annex F.3 “Character-Oriented Serial Stream (COSS) Client”, December 2008

Ready to request an Evaluation?

Thankyou for considering Isode’s software products. To request an evaluation, please select the product(s) you are interested in, then fill out the enquiry form.

Select your Evaluation products: