Security and Authentication for the CAP Data Server

by Cyrus A Dolph V

Executive Summary

The security needs of the CAP component of NASA's CTAS system have been identified and analyzed, and a number of security software packages have been considered for use in the system. The final recommendation is to use the Secure Shell (SSH) software to provide public key authentication of the CAP data server to its clients and to provide strong encryption of the sensitive data streams. This package was chosen because it will be extremely easy to implement, and is available at an affordable price: the SSH server software will cost approximately $500, while each client costs an additional $100.

Problem Analysis

Overview of CAP and CTAS

NASA's Center TRACON Automation System (CTAS) is a sophisticated set of tools designed to assist air traffic controllers in planning efficient and safe flight patterns. CTAS is a very large piece of software with many components, and it is still a product in development. So far it has been partially installed with encouraging success at facilities serving the Dallas/Fort Worth airport.

The Collaborative Arrival Planning (CAP) module will be a new feature of CTAS that will allow airlines to access up-to-the-minute flight status information about their airplanes (currently, real-time flight information is not available to airlines). CAP will also provide a mechanism for airlines to participate to a limited extent in the air traffic control process by assigning priorities to their flights. This will help airlines to reduce timing miscues associated with delayed flights and result in fewer missed connections, increased revenues, and hopefully a reduction in rush conditions at airports.

The preliminary design of this module involves the specification of a CAP data server that will acquire and store all relevant air traffic information from the CTAS Communication Manager. This data server will communicate with airline operational control centers over AOCNet, the high bandwidth private network shared by the airlines and the FAA, and supply to each airline up-to-date flight information about its flights. Essentially, the server will be a high volume multiuser database. A feedback channel will also be implemented that will allow airline controllers to submit scheduling requests back to the CTAS system in response to this data - the requests might be routed back through the CAP database server, or they might be sent directly to relevant tools in CTAS.

Problem Statement

The objective of this project is to design a security system that provides authentication and privacy services for airlines querying the CAP database and submitting traffic control requests to the CTAS servers.

Goals of the CAP security system

The design of the security system should provide the following functions:

Authentication and Integrity

Currently, it is anticipated that dozens of different airlines will be accessing CAP within the next decade. The CAP security system must supply a mechanism by which the database servers can verify authorship of incoming communications, and vice versa. It must not be possible for an unauthorized party to impersonate an airline or the CAP server. Nonrepudiation may also be a concern for CAP - is it a priority that no airline should be able to plausibly deny sending an authenticated scheduling request?

Authorization

The CAP database server must obviously restrict the access privileges of its client airlines. Airline A should not be permitted to access data or submit scheduling requests for airline B's flights. Additionally, multiple levels of authorization may be desirable for some clients, as different airline personnel may have different duties and permissions within the system. For example, some personnel may only have permission to view traffic information, while others will need permission to submit scheduling requests, while supervisors will likely need to have certain administrative privileges.

Privacy

The communications between airlines and CAP must be secured to guard against the disclosure of confidential information about airline flight schedules to unauthorized parties. Depending on how the database query and response protocol is implemented, different levels of security may be required for data transmitted in different directions.

Administration

The CAP security system will need to provide administrative functions and protocols. Any cryptographic systems that are employed will require the implementation of protocols for key distribution and for the handling of initial key generation, lost-pass-phrase emergencies, etc. There should also be a well-defined procedure for dealing with pending attacks, such as denial-of-service attacks.

Considerations

Information Value

In selecting a security system, perhaps the most important variable to evaluate is the value of the information that it must keep secure. The value of an airline's current flight schedules is certainly very high. However, the rate at which the value of this information decreases with passing time remains to be ascertained. Clearly, data about last month's flight schedules would be less important to a competing airline than information that is minutes old. In recommending a solution, this project will assume that it is absolutely critical that flight information be protected for at least several hours, and that this information should remain secure for a period of at least one month against any attack mountable by an anticipated adversary (see below).

Identification of possible adversaries

CAP is entrusted with a large amount of valuable information that it must protect from unauthorized parties. But what kinds of unauthorized parties are likely to attack the system? Assuming the system is isolated from the public because it resides entirely on the private airline network AOCNet, the airlines themselves will be in the best position to attempt to crack it. It is not entirely unreasonable to expect that some airlines have invested impressive amounts of money in industrial espionage efforts; a rogue airline might be able to devote considerable resources towards cracking CAP, although they obviously won't have the funds and expertise of a major government. It is certainly the case that the less well secured CAP communications are, the more likely airlines will be to consider attacking them.

As CTAS tracks military and high profile aircraft such as Air Force One, it is possible that a terrorist organization or hostile government would attempt to gain tracking information on these craft through CAP. Of course, as CAP has no need to track these aircraft, this information should be cut off from the system by the CAP Spy. This project assumes that flight information transmitted over the AOCNet will not be of importance to national security, and therefore governments will not be included on the list of possible adversaries.

Other possible adversaries include the common malicious Internet cracker who might seek to cause damage to the airline industry. While CAP only serves airlines who are connected to it through AOCNet, it is likely that this network is not as insulated from the outside as desired, as many airlines probably have computers connected to both the private network and the public Internet. In designing the CAP security system, it is appropriate to assume that all communications are being transmitted over public channels.

Trust boundary

Where will the lines of trust be drawn in the system? In any security system, there must be a reliance on trust at some points, and a complete distrust of other areas. For example, the software running inside the CAP servers themselves must be trustworthy, while any information transmitted over the private airline network should be considered to have been broadcast over a public medium.

Some information transmitted by the CAP server and clients will not be sensitive - computation time and programming effort might be saved by only securing those certain parts of the client-server information stream that are deemed private. A scheme might even be developed whereby private information is manipulated by reference instead of through explicit labelling; e.g. a flight information record might be referred to by a special request number instead of by its official flight number so that an onlooker would have no idea what plane was described by the data. However, if such a protocol is employed, considerable care must be taken to ensure that no sensitive data is accidentally left exposed due to an imprecise analysis of what information is being conveyed by various types of messages.

Accountability

Since the users of this system will be large corporations who will be very interested in maintaining their access to CAP, they will be more likely to follow any rules if getting caught breaking them could mean termination of service. If the system can be designed such that tampering with it will surely result in discovery, then there will be a large incentive not to attempt to crack it.

Dangers of a cryptographic approach

The CAP security system will certainly employ a cryptographic authentication system, and will likely use encryption to protect at least some of its communications, as cryptography is the standard method for solving problems of this kind. In analyzing a cryptographic approach, it is very helpful to identify any difficulties inherent in the problem. There are certain types of attacks that will be of concern for CAP due to its nature:

Replay attacks

These attacks crop up all the time in authentication schemes: if an intruder can fool a server into thinking he or she is a legitimate client by replaying that client's authentication transmissions, then a serious breach of security has occurred. These attacks can theoretically be guarded against using timestamps, but that method requires closely synchronized clocks.

Known plaintext attacks

CAP database queries and results will likely have a regular, predictable format, which means that the encrypted forms of these communications will be vulnerable to known-plaintext attacks. If encryption is used, the chosen algorithm must be secure even when an attacker already knows part of the plaintext of the message. The best encryption algorithms ensure that each bit of the input has a large and nearly unpredictable effect on the bits of the output, so that the encrypted output appears to be a random function of the input.

Denial of service attacks

Thanks to the private airline network, there is some protection against denial-of-service attacks from parties outside the system. Still, this will possibly be an important vulnerability, as an overload of the system could potentially cause a lot of monetary damage to airlines that depend on its functionality.

Practical Matters

Bandwidth

AOCNet is the national high bandwidth private network for the airlines - it is possible that some airlines are not connected to it, and will have to rely on other means of connection to CAP. This is more of a bandwidth consideration than a security concern, since the final design should hopefully be secure enough for any public network.

Speed

Encryption is slow (although with today's advanced hardware, it's not such a big problem as it once was). In any case, the security system must not be so cumbersome that it acts as a bottleneck for the rest of the system.

Scalability

Designing a system that will scale well with increased traffic and increased airline participation is not a priority, as CTAS is not expected to grow significantly in those aspects in the near future.

However, the scalability of cryptography is a very relevant consideration for CAP: any cryptographic algorithms employed should be easily modified to utilize larger keys in the future to make the system defensible against stronger brute force attacks that will no doubt be possible soon.

Political Issues

Export control laws

The United States has some complicated laws about exportation of cryptography. If CAP uses any strong encryption software, then these export control laws may be relevant, as CAP will be serving foreign airlines operating within the United States. The best way to circumvent export control concerns will be to import all encryption software from overseas.

Investigation

Now that the problem has been defined, a solution must be found. In the remainder of this document, a variety of appropriate general approaches to authentication and encryption are discussed before a set of specific software packages are considered and a final solution recommendation is made.

Authentication

Symmetric Key Cryptography or Public Key Cryptography?

There are two standard approaches to authentication in the industry today: symmetric key cryptography and public key cryptography. Authentication based on either of these methods could provide an acceptable solution for CAP security. A symmetric key authentication system (such as Kerberos) would require a trusted key distribution center (KDC), and would have a number of advantages and disadvantages if employed to secure CAP: If a symmetric security system were implemented for CAP, the KDC would be most logically installed in the same facility as the CAP server. Each client would have a security module that would authenticate itself to the KDC in order to initiate a mutual authentication with the CAP server, and later negotiate a secure communication channel with the server.

Public key authentication systems boast a number of improvements over symmetric key authentication, most of which wouldn't affect a situation like the CAP environment. However, public key systems are especially attractive because they usually do not require a dedicated KDC. The computers of CAP would be responsible for storing the public keys of only those computers with which they communicate - the data server would have every client's public key, while the clients would only need to know the server's public key. Also, there are many more public key cryptography products available from which to choose.

Privacy

The best way to guarantee protection of CAP communications against eavesdropping is through encryption of all transmissions that are sent across public channels. Although much of the data sent between the CAP server and its clients won't need to be kept confidential, it is easier to encrypt it all than to worry about creating separate channels for different kinds of data (as mentioned above, there is always the concern of unwittingly disclosing sensitive information due to an oversight in the protocol). Perhaps even more importantly, however, this design choice has the significant advantage that it allows the security module to be transparent to the rest of the CAP system (whose design is still in the beginning stages at the time of this document's construction).

In selecting an encryption solution, the two most important criteria are speed and security. There are about a dozen widely used encryption ciphers, each with its own advantages and disadvantages. In general, an algorithm becomes more secure if it uses a longer key, but it also becomes slower. The DES algorithm recommended by the NSA is very fast but is generally agreed to be insecure thanks to its mere 56 bit cipher key length. Most experts recommend algorithms with key lengths that are greater than 64 bits when protecting data for extended periods of time. Triple-DES and IDEA with their keys of more than 100 bits are generally trusted to be secure for most purposes, as it is estimated that even a government would need years to crack these algorithms via standard brute force techniques.

Authorization

The issue of authorization is best handled not by the CAP security system, but by the CAP database itself. Each AOC client will need to have various permissions to the CAP database, which will be judged by the CAP server itself. The security system will only help to solve the authorization problem by guaranteeing the authenticity of requests; it will be unable to determine if the requests are valid. Each airline will be responsible for managing its CAP database privileges as it sees fit; some airlines may wish to install an additional layer of authorization between the client security module and the AOC client software to divide the responsibility of using CAP among different personnel.

Of course, CAP security will have to rely on some administrative structure that will involve the use of authorization protocols for conducting maintenance operations, etc. However, the details of this authorization scheme are of secondary importance to the rest of the security system.

A Survey of Available Software

A few potentially suitable security systems are discussed here.

Kerberos

The popular Kerberos symmetric key authentication system would be well suited for CAP for a number of reasons, although there are also some concerns: As Kerberos is only an authentication service, it must be coupled with encryption software if it is to be used to secure CAP. Unfortunately, the basic Kerberos packages available from MIT include only a DES-based encrypted telnet application. As DES is widely believed to be insecure against governments and large corporations (such as airlines), it is not recommended for use in CAP. Commercial vendors of Kerberos-based security software (e.g. CyberSafe) do offer packages with strong encryption, although these products are almost certainly not exportable.

KryptoKnight

KryptoKnight is a Kerberos-like authentication system developed by IBM that addresses many of Kerberos' flaws.

Secure Socket Layer

The Secure Socket Layer (SSL) is a security system developed by Netscape for use in web browsers. SSL normally uses public key cryptography, but also supports (at least according to the specification) symmetric key authentication.

Secure Shell (SSH)

SSH is a very popular network security tool developed in Finland. Its primary function is to provide a secure remote login shell, although it can be used to secure any data stream. A commercial version of the latest SSH server (Version 2.0.13) costs about $500, and SSH client licenses cost about $100 each.

Recommendation

Although all of the above systems could be used to secure CAP, SSH suggests itself as one of the most cost-effective solution to CAP's security needs. Its primary advantage is that little code will be needed to incorporate it into the design of CAP, since it supplies so much functionality in one package and has a well-designed interface. Also, SSH stands out among its competitors because no additional computers will be required to run it (unlike Kerberos and KryptoKnight systems which need a KDC), and because it avoids export-control concerns (unlike SSL and others).

Implementation

The implementation of a SSH-secured CAP system should not be very difficult. The CAP data server will run a SSH daemon that will allow AOC clients to connect to it and establish encrypted, authenticated communications streams. Each AOC client will be given a special user account on the data server that allows it to run a server connector program to communicate with its database thread (these accounts will not have UNIX login shells available - they will only be able to run a CAP Connector program to communicate with CAP streams). The server will be able to authenticate the clients because each client will only know the password to its own account (alternatively, RSA authentication could be used, as it is supported by SSH). Each client will be able to authenticate the server because it will have a copy of the CAP data server's public key (this copy will have been delivered by mail to the airline). And of course, SSH will ensure that the connection between the client and server is private, using strong encryption, such as the 128-bit IDEA cipher.

As a further security feature, it is recommended that the FAA Firewall be configured to protect the CAP server by limiting access to the server's SSH daemon port to IP addresses corresponding to authorized clients, if this is possible.

An important implementation challenge will be constructing the server connector program which allows SSH to encrypt communications between CAP client threads and their remote AOC hosts. Attaching the database query stream to an SSH connection is a matter of UNIX pipe manipulation, assuming that all such communications can be channeled in a single stream (SSH also provides a TCP/IP port-forwarding service, but if this were used in lieu of SSH's standard telnet-style connection there is no obvious way to guarantee that one client wouldn't be able to snoop on another's port at the server). A similar connector will have to be installed on the client side.

Administrative Details

Once the basic encryption and authentication mechanism is determined, administrative details must be decided. The lifetime of host keys and user passwords, protocols for key replacement, and maximum session length all need to be determined, although some suggestions are listed below. Since SSH uses large keys (1024 bits is the default size for host keys, and 128 bits is the key size of the IDEA cipher session key), it will be acceptable to have long key and session lifetimes. The server host key might be replaced every several years (or even decades) without fear of compromise, and day-long sessions would certainly be appropriate when using IDEA. As for the client passwords, they should have a lifetime of about a month or two, as passwords are the system's weakest link due to their vulnerability to dictionary attacks. If RSA authentication is used instead of password authentication then there will be no need to change RSA keys more frequently than the server's host key, although it would be prudent to change the passwords that protect the RSA private key on a semi-monthly basis.

Security Evaluation

SSH's public key authentication system is resilient enough to resist man-in-the-middle and replay attacks as long as its users pay heed to the warning messages it supplies when they are encountered. For example, when a different host public key is supplied to SSH, it reports that a man-in-the-middle attack may have been mounted and offers the user the option to accept the new key or not. Because the CAP server host key will never be changed without notice, it is desirable that SSH be configured never to accept new host keys (unless they are explicitly installed by a local system administrator). However, this configuration feature is not currently available.

Although the FAA Firewall likely provides some defense against denial-of-service attacks, a CAP-specific mechanism for detecting and neutralizing such attacks might be desirable. Although denial-of-service is not a priority concern thanks to the relative isolation of AOCNet from the public, it would still be prudent to employ safeguards to defend against it. This project has no recommendations on the matter at the time, however, and leaves it as a subject for further study.

Performance Analysis

An informal test has been conducted to determine how taxing SSH's cryptographic computations might be for the server. The test involved the opening of a number of SSH connections to a server and transferring a large amount of data over the connections simultaneously. The server and client were both PC's with AMD K6 processors connected via 10 Mbps Ethernet. When transmitting files using SSH's scp utility with the IDEA cipher, the server averaged a CPU load of approximately 30% of capacity, while the client averaged a 70% CPU load. The data transfer rate achieved was slightly less than 600 kB/s. The total transfer rate and CPU load did not appear to be affected when multiple connections were opened simultaneously: if two connections were open, their processes would equally split the CPU usage and transfer rate achieved by a single connection. A control test was run in which the same files were transferred using the FTP protocol: in this test, the server was only loaded to 5% of capacity, while the client was loaded to approximately 15% of capacity. FTP achieved a transfer rate of about 800 kB/s. When compared to a T1 line's maximum theoretical transmission speed of about 180 kB/s, these numbers are very encouraging.

It is anticipated that a current generation Pentium III processor would perform these encryption computations considerably faster than the test machines. If the CAP data server is too loaded to handle encryption, the addition of an additional processor dedicated to encryption computation should be ample to meet the system's computational needs.

Conclusion

SSH offers a cheap, efficient and secure solution for CAP's security needs. While a fancier design could no doubt be constructed from scratch to fit CAP's needs more closely, SSH addresses all of the major needs of CAP with a single software package, making it a very attractive answer to the problem.

Appendix: CAP Security Technical Notes

This appendix decribes how to install SSH (version 2) on a Linux computer and provides an example of how it might be configured for use with CAP. This is intended as a supplement to the SSH documentation, and should not be considered as a manual.

Sample SSH Installation

SSH2 can be obtained from SSH Communications Security, Ltd., at http://www.ssh.fi. Their downloads page is located at http://www.ssh.fi/sshprotocols2/download.html.

The procedure for installing the SSH server daemon (sshd2) and client (ssh2) is well described in the software's documentation.

Configuring a client

For this example, DSA public key authentication will be used.

Key management

Each airline client must have a DSA public/private key pair in order to connect to the CAP server. The private key is known only to the client, while the server has a copy of the public key stored in the user's .ssh2/ subdirectory. Generating the key pair is done by executing the ssh-keygen2 command, which will generate the key pair, and ask the user to supply a pass-phrase to protect the private key. The public key will need to be given to the CAP server administrators so that it can be added to the client's remote .ssh2/ directory. The private key must be mentioned in the .ssh2/identification file; this is done by adding the following line to the file:

IdKey clientprivatekeyfile

The client will also need to have the CAP server's public key stored in its .ssh2/hostkeys/ directory. For added security, public keys should be delivered via mail - if they are intercepted, it will be possible to mount a man-in-the-middle attack.

The CAPClient program

Since the CAP Client software has not yet been designed, it is unknown how it will interface with the server through SSH. Presumably, its communications will travel in two streams, one for input and one for output. If these streams are attached to UNIX FIFO's, then they can be attached to the SSH process when it is executed. This can be accomplished with a script similar to the one below:

mkfifo f1; mkfifo f2;
ssh2 -l username caphostname.something.gov < f1 > f2 &;
CAPClient > f1 < f2;

The CAPClient must be able to recognize and answer SSH's pass-phrase challenge (an easy programming task). Once SSH establishes the secure connection with the server, the CAPClient application will be directly connected to the CAPConnector program on the CAP server, and can begin to transmit queries.

Configuring the server

Host Key

When SSH is installed, a hostkey pair is generated. The private key will be stored on the server, and copies of the public key will be distributed to the clients via a secure method.

User Accounts

The server should provide special accounts for each of its client users. Each user will have a home directory as normal, but will only be allowed to execute one command, the CAPConnector program. This is done by setting the user's shell to be the CAPConnector program:

# chsh airline1 -s /CAP/bin/CAPConnector

The CAPConnector program is responsible for connecting the client's communication streams (there is an input and an output stream) to the CAP data server, completing the client-server connection through SSH.

Each client will need a .ssh2 subdirectory in its home directory on the server, where the client's DSA public keys will be stored. The public key will need to be mentioned in the .ssh/authorization subdirectory on the server so that SSH can authenticate the client. The .ssh/authorization file will contain the line

Key clientpublickeyfile

Server Security

Installing SSH alone is clearly insufficient to guarantee security of the CAP server. A system administrator should be able to review the system's configuration in search of security risks, and reduce them by removing unnecessary services, patching out-of-date software, etc.
John Chapin
Last modified: Fri May 21 11:59:46 EDT 1999