Issues with ATN UL Security Framework
Ref : TRS054/T06/DEL/D01
ACP WGN04 WP 36
27 October 2004
AERONAUTICAL COMMUNICATIONS PANEL (ACP)
WorkinG group N (NETWORKING)
New Orleans, 10th– 19th November2004 (fourth meeting)
Agenda Item 7.2Security Technical discussions
Issues with ATN UL Security Framework
Presented by EUROCONTROL
Summary
This working paper identifies some issues with the current ATN security framework, as invoked by the Upper Layers Communication Service.
Version: 0.BDate: 27 October 2004Page: 1
Issues with ATN UL Security Framework
Ref : TRS054/T06/DEL/D01
1.Introduction
ATN security provisions were first published in the Third Edition of ICAO Doc 9705, after several years of development by the ATNP Security Subgroup.
The security provisions were designed to counter the threats identified in the original EUROCONTROL threat analysis for ATS communications, and as such provide the following services:
Data Integrity: Messages are protected end-to-end with a 32-bit Message Authentication Check (MAC), which prevents undetected modification or replay attacks.
Peer Entity Authentication: The session key used to derive the MAC is derived from the public and private "key agreement" keys held by each peer, and is unique to that pair of applications. The source and destination identifiers are included in the scope of the MAC and therefore a recipient can be sure that the message originated from the claimed peer, thus preventing masquerade attacks.
2.What is missing?
Confidentiality. Since protection of ATS messages from eavesdroppers was not originally identified as a requirement, no confidentiality (data encryption) service is included in the current security provisions. However, if ATN is to be used for AOC communication, it is important to airlines that commercial or sensitive (e.g. passenger-related) information should be encrypted. Also, military users of civil ATS services may wish to protect information such as source and destination aerodromes from prying eyes.
Connectionless Security. Since all current ATN applications are connection-oriented, there was no requirement initially to extend the ATN security services to connectionless communications. The connectionless dialogue service (CLDS) was first published in the Third Edition of ICAO Doc 9705. (The connectionless transport (CLTP) and network (CLNP) services have been present in all editions of the ATN Technical Provisions). GACS, the first application capable of using the CLDS, was also published in the Third Edition.
3.What are the problems?
3.1Complexity
Implementers have complained that the ATN security provisions are "too complex." However, other implementers have successfully developed conformant software.
Part of the "complexity" perception comes from the inclusion of detailed cryptographic parameters in Sub-Volume VIII, plus the use of security terminology and algorithms that may be unfamiliar to many communication product vendors.
Another perceived problem is the convoluted structure of the Control Function in Sub-Volume IV. In fact there are two CFs;
- The "outer" dialogue service CF controls the interactions between the Application ASE (e.g. CPDLC air or ground ASE), the Security ASO, ACSE and the supporting transport service.
- The Security ASO itself contains an "inner" CF, which controls the interactions between the S-ASO upper and lower service boundaries, the embedded SESE upper and lower service boundaries, and the SSO.
The situation is exacerbated by seemingly complex ASN.1 structures in Sub-Volume IV, particularly in the security exchange data types constructed by the ISO-standard SESE. "Information Object" definitions SECURITY-EXCHANGE and SEC-EXCHG-ITEM are imported from the OSI security framework; they are not widely understood. The specification of SESE APDUs uses advanced ("difficult") ASN.1 constructs, which may not be supported by some ASN.1 toolkits.
However, the Sub-Volume IV Guidance Material (Draft Doc 9739 Ed 2) explains how the ASN.1 types are encoded as straightforward bit sequences.
It might be possible to simplify the structure of the security provisions by eliminating some of the abstract service invocations. For example, the Security ASO could be eliminated, the SSO could be invoked "inline" from the DS-CF, and the final PDU constructed directly rather than by invoking the SESE. This would certainly make the processing easier to follow, though it would destroy the modular structure of the specification, which is based on OSI Application Layer Structure object-oriented principles.
3.2Overheads
The use of ATN Security does not currently add any additional message exchanges compared to the non-secure case. (With the addition of Confidentiality, an initial null message exchange may be required). However, it does add significantly to the total bits-on-the-wire count, due to:
- all application PDUs are wrapped in a SESE APDU
- CM Logon downlink messages have a 40-octet digital signature
- Other messages have a 32-bit MAC tag
- CM Logon response uplink includes the public keys of ground applications.
Reducing the bit count was one of the primary motivations of the Security Subgroup, and the current solution is probably optimal for the high degree of security obtained.
3.3Cryptography
Elliptic curve cryptography (ECC) is not as widely known as some of the more established algorithms, and COTS modules are not so widely available. However, ECC was deliberately selected to minimise the required communication bandwidth, due to its relatively shorter key lengths.
3.4Key Distribution
Key distribution will always be a challenge for key-based security solutions. Public key cryptography was developed to ease the problem of delivering secret keys confidentially.
The ATN security solution assumes a "Key Distribution Function" without specifying how it is implemented. The fact that it uses X.509 certificates for public keys, and Chapter 8.4 is entitled "ATN Public Key Infrastructure" implies a strong pre-disposition to a Directory-based PKI.
3.5Cost
The Ed 3 security solution is perceived as expensive. This is largely due to a combination of the above factors. If the amount of code requiring development to DO-178B Level C assurance level can be minimised, then costs would be lower.
Experience has shown that Certificate Authority implementation need not be costly.
3.6ATN Upper Layers
The Ed 3 dialogue service minimises the impact of security on applications by handling all security-related operations on their behalf "beneath" the dialogue service interface (DSI). All that the application has to do is set the Security Requirements parameter to the required level when opening a dialogue using the D-START service.
Three values of the Security Requirements parameter are currently available:
- "No Security" – the Security ASO is bypassed, and the Upper Layers behave exactly as in earlier editions of Doc 9705.
- "Secured Dialogue" – All application messages exchanges over the dialogue are protected by a MAC.
- "Secured Dialogue Supporting Key Management" – An initial exchange is performed using digital signatures, in order to establish a "security context" between end systems. The protected data will usually include compressed public key certificates. The resultant shared information is then used in the calculation of session keys for subsequent exchanges.
A problem with the current specification is that no explicit partitioning, or "subsetting" of the ULCS provisions is specified. Thus it might be thought that all implementations conforming to Doc 9705 Third Edition are obliged to implement all Sub-Volume IV requirements.
If "No Security" is the required level of support for a particular application (or a particular region), then the communication stack supporting that application should not have to implement all the security provisions.
If "Secured Dialogue" is the required level of support, then the communication stack should not have to support all the functionality required only for the initial key exchange.
Sub-Volume IV should be clarified to specify exactly which requirements are applicable to each class of application.
3.7The Impact of PM-CPDLC
"Protected Mode CPDLC" was developed in response to operational hazards identified for profile-changing CPDLC messages. It consists of a user-level 32-bit checksum appended to all CPDLC air-ground messages.
In many ways, the checksum is similar to the MAC used to provide security. The obvious question then is "Why not simply replace the PM-CPDLC checksum with a cryptographic checksum, and hey presto we have a simple security solution?"
Unfortunately, things are not so simple. Firstly, there is still the complexity of the cryptographic algorithm to contend with, as well as the attendant key distribution problem. Secondly, it has not been proven conclusively that a 32-bit MAC provides the same level of protection against communication errors as a 32-bit checksum. The MAC and checksum were defined for different purposes.
Suppose that a MAC can be shown to protect effectively against communication errors, so that the probability of an undetected error is "remote." Then, the MAC could be computed and verified at "user level" and could replace the PM-CPDLC checksum field. There is then the question of the symmetric private key to be used in MAC calculation.
Aircraft operators and ANSPs would have to possess the same key for each aircraft. This could perhaps be accomplished by pre-loaded lookup tables. The pilot could carry a secret token onto the flight deck for each flight, leaving a corresponding token on the ground, which could be communicated to other ground centres over secure ground networks.
It would seem much more straightforward, and a better validated solution, to use hybrid cryptography, so that the session key is derived from shared public and secret private keys. Then, only public keys have to be communicated.
4.Recommendations
The Working Group is invited to consider the following recommendations:
- Allowable subsets of the secure ULCS should be specified, so that the required security functions for a particular application can easily be extracted, and those provisions that are not applicable to that application can be omitted.
- If future applications, as is foreseen, may be based on connectionless transactions, then CL security provisions should be developed as a high priority.
- If the ATN is to be acceptable for AOC and military ATS, then the confidentiality service should be completed.
- Consideration should be given to re-working the ULCS to remove the Security ASO and invoke SSO and SESE primitives, when needed, directly from the Dialogue Service control function.
- A "simple security" service, which is not dependent upon CM, should be developed as a stepping-stone towards full ATN security. It would be acceptable for this to be "less secure" than the end state, while still protecting against realistic threats.
- A "roadmap" for ATN security deployment should be developed. This might, for example, be along the following lines:
Version: 0.BDate: 27 October 2004Page: 1