Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Whitepapers

AMHS Security

 

The Aeronautical Traffic Services (ATS) Message Handling Service (ATSMHS) defines a set of security services for use as part of the Extended ATS Message Service for providing that ATS Message Handling System (AMHS). This White Paper describes these security services, how they are provided and how they can be deployed. The paper concludes that AMHS Security is needed now, and should be pursued urgently as a part of AMHS deployment.

AFTN and the Basic ATS Message Service

AFTN is the currently deployed global infrastructure for ground to ground messaging, which AMHS will replace. The Basic ATS Message Service is a subset of AMHS that provides a similar level of service to AFTN to help the migration from AFTN to AMHS. By contrast, the Extended ATS Message Service includes service capabilities that go beyond those provided by AFTN.

AFTN and the Basic ATS Message Service do not have application level security. Security of the application relies on the operational approach of the servers and network links having good physical security and that they may only be accessed by trusted personnel. While in practice this offers fairly good security, this is not ideal. Concerns with the current situation:

• Having security at the application level to complement lower level security is intrinsically desirable.
• Post 9/11, security is generally a higher concern for operators.
• Relying on the trust of all personnel who might be able to get access to a message in transit, or who might be able to get access to a terminal is undesirable.
• A message could be lost or modified due to errors in intermediate systems or networks.
• There is a move from use of dedicated lines for supporting AFTN link to using shared network services, which increases the opportunity to attack messages in transit.
• Access to the infrastructure is, at least to some extent, being opened up. For example, facilities are being provided for Web access to the ATS Message Service and AFTN. This could give rise to new opportunities to inject forged messages.

These concerns clearly justify the consideration of application security measures.

Security Services Provided by AMHS

AMHS, as part of the Extended ATS Message Service, provides two security services:

• Content Integrity. This ensures that a message has not been tampered with or otherwise modified in transit. It would protect against accidental message damage, and also against malicious message tampering by someone who had access to the message queues of messages in transit. It does this by verifying to the recipient that the message is unchanged.
• Origin Authentication. This enables a message recipient to verify (by digital signature) that a message comes from the claimed sender. Use of this service would protect against the threat of forged messages being maliciously injected into the system, because the forger would not be able to fake the digital signature.

These two services provide protection against two very clear security threats to the messaging infrastructure.

How AMHS Security Works

The provision of these two security services using X.400 is straightforward. The security technology to provide this is based on X.509 digital signatures, supported by PKI (Public Key Infrastructure). Information on this supporting technology is provided in the Isode White Paper A Short Tutorial on Distributed PKI.

Both origin authentication and content integrity are provided by something called a MOAC (Message Origin Authentication Check). A MOAC is created in two steps:

1. Build a hash of the message (a short checksum of the message) using a cryptographically secure hash mechanism, such as the well known SHA-1 (Secure Hash Algorithm 1).

2. Build the MOAC from this hash using the private key of the message originator.

Anyone with the public key of the originator can reverse this process, by using the public key to extract the hash and then checking that the hash is the same as one built locally against the message received. It can be seen that the MOAC provides both the Origin Authentication and Content Integrity services.

The MOAC is sent along with the message using a standard X.400 envelope field. In order to make life easy for the message recipient, a second parameter may be sent with the message which is the originator’s certificate (containing the originators public key). This provides the recipient with all of the information needed to verify the MOAC. If the certificate is not sent and the recipient does not have it, the recipient would typically use a directory service to find the certificate. It is recommended to send the certificate as well as the MOAC, at least until suitable directory services are internationally deployed.

All this functionality can be built into the underlying software in a manner that is transparent to the end user.

Additional Security

There are other X.400 security services that AMHS has chosen not to use, such as content confidentiality. AMHS has also avoided the complexities of security for Military Messaging by making use of native X.400 security capabilities. This appears to be a sensible choice, as focus on the most important features will make rapid adoption much easier.

It is worth noting that applications can obtain protection against message loss (which could be due to malicious removal of a message) by using two techniques which could be built into the applications or into operational procedures.

1. Message level acknowledgement. If a message (IPM - Interpersonal Message) or message level acknowledgement (IPN - Interpersonal Notification) is sent back (with Origin Authentication for the message or notification sent back), then the originator can be confident that the original message was received.
2. Message sequence numbering. If messages are numbered, the recipient can detect if a message is missing.

How AMHS would appear to the end-user

It is useful to consider how AMHS Security might change things for the end user.

• AMHS Terminal. The hardware of the AMHS Terminal solution might have the addition of a smart card reader (if smart cards are to be used), and some minor changes to the software.
• Authentication. Use of password will either be dropped or replaced by use of a pass phrase to access smart card or local software key.
• Sending a message. The user may choose to set security for messages in some implementations. It is more likely that the use of security will be automatic, and not under user control.
• Receiving a message. Secure messages may be marked, so that the user is aware as to which messages received are secure. If a received message fails a security test, it may be hidden from the user or shown with a security warning, dependent on local policy.

In summary we can see that the changes, as far as the end-user is concerned, would be minor.

A Model for National Deployment

It is useful to consider how a single CAA could deploy AMHS Security. This section sets out a simple model, which would be appropriate for many CAAs. The issues to be addressed for a complex national deployment would be similar to those faced for International deployment discussed later.

The first step will be to obtain AMHS Client applications that can support AMHS Security, such as AMHS Terminals for all users that require security.

The second step is to obtain a Certification Authority (CA) to be operated by the CAA. There are many products available on the market from vendors such as RSA and Entrust. This will be used to issue certificates for each user. There are two basic choices that the CAA can make (or a mix of both):

1. Smart Cards. In this model, AMHS clients will be equipped with smart card readers. Smart Card and CA vendors provide solutions for issuing smart cards in conjunction with a CA.
2. Software. Here, the private key is stored on the disk of the computer running the AMHS client. Generally, the private key will be encrypted with a pass phrase to be supplied by the user. In this model, the private key will be generated as part of the AMHS client system, which will interact with the CA to create a certificate. This process is described as part of the description of Isode's Mini CA, which is a CA designed for use with demonstrations and very basic deployments.

Once certificates are issued to each user, secure AMHS can be used for communications within the CAA.

Interoperability and Co-Existence

An important feature of AMHS Security is that it is implemented by additional X.400 envelope fields, without changes to the message being carried. This makes co-existence with clients that do not support security to be very straightforward.

It is strongly recommended that all AMHS Clients, particularly those which do not support security, are tested to ensure that they can receive the AMHS Security fields. Correct behaviour (which is likely) is that the client should simply ignore the security fields and otherwise process the message as it would do normally.

The key benefit of being able to rely on this client behaviour is that it makes it much more straightforward to deploy AMHS Security. For a full deployment of the Extended ATS Message Service, the ATN Directory should be used to verify the capabilities of each recipient. This is an elegant solution, and Isode advocates use of the ATN Directory.

However, if all clients (including AFTN/AMHS Gateways) can receive secure AMHS messages, security can be deployed very easily in a closed AMHS environment. In order to handle more complex deployments, clients will have to check recipient capabilities in the directory. This means that directory deployment needs to be considered in parallel with security deployment.

Options for International Deployment

Once national deployment of security is achieved, the next step will be deploying between organizations. There are three areas to consider:

1. The mechanics of signing messages (creating the MOAC). No change.
2. The requirements on National CA/Certificate infrastructure. No change.
3. Originator decision on whether or not to sign a message. If the recipient only supports the Basic ATS Message Service, the message should not be signed. The originator will need to perform a look up in the ATN Directory in order make this decision. A consequence of this is that ATN Directory needs to be deployed in a country before secure AMHS can be effectively used. Further information on directory deployment is given in the Isode white paper Deploying ATN Directory with AMHS: What you can do now.
4. Message verification. The basic verification, using the public key in the certificate sent with the message, is unchanged. However, the problem of verifying the public key is more complex. This problem is discussed in the rest of this section.

Verifying the originator’s certificate is the core function of PKI (Public Key Infrastructure). Background and more information is given in the Isode White Paper A Short Tutorial on Distributed PKI. For simple deployment in a single CA, the originator and recipient will use the same CA. This means that the recipient will be configured to trust certificates issued by its own CA and thus will trust the originators certificate.

Where originator and recipient have different CAs, a number of approaches are possible.

1. Configure the recipient to trust the originator's CA. For example, all DFS users could be configured to trust the NATS CA, which will enable the DFS users to verify messages from NATS users.
2. Configure the recipient to trust the originator's certificate. For example, when an Aena user receives the first signed message from an FAA originator, the recipient will mark that FAA originator’s certificate as trusted. This will not add any security for this message. However, subsequent messages can be verified using the same (now trusted) certificate. This approach essentially builds trust through repeated use.
3. Build a PKI trust chain between the originator's CA and the recipient’s CA, using the PKI mechanism of cross-certification, where CA’s generate certificates for each other. This can be done directly between the CAs, which will be convenient for early deployment. For example the NATS CA and the FAA CA can cross certify, which will build a trust chain between all NATS and FAA users. It may also be done indirectly. For example, the Aena and DFS CA’s can each cross certify with the ICAO CA, which will lead to a reduced requirement for cross certification when many countries are using secure AMHS.

Conclusions: Why AMHS Security is needed now

AFTN and Basic ATS Message Service do not have security, and rely on the security of the underlying environment. This is undesirable.

AMHS Security offers a way to address the threats of message tampering and message forging using a straightforward mechanism that can easily co-exist with both AFTN and with the Basic ATS Message Service. The components to build AMHS Security are (or will shortly be) available in the market. These should be used to address the problem.