3. Cryptography in the ATN
3.1 Overview of the ATN

3.2 The Security Concept of the ATN

3.2.1 Application Security Solution

3.2.2 Public-Key Infrastructure

3.2.3 Cryptographic Details


3. Cryptography in the ATN

3.1 Overview of the ATN

The Aeronautical Telecommunications Network (ATN) is defined and standardized by the International Civil Aviation Organization (ICAO) in ICAO document 9705. It forms an integral part of the future global communications, navigation and surveillance concept. The ATN is a fully scaleable network and offers prioritized end-to-end communications, policy based routing procedures and a high service availability to meet the stringent performance and safety requirements needed in an air traffic control environment. It is based on the OSI (Open Systems Interconnection) reference model to provide interoperability in data communications over different networks. The ATN offers a robust and high integrity communication service between two end systems, either at fixed locations or between an aircraft and a fixed location. The ATN Standards and Recommended Practices (SARPs) define the data communications architecture and protocols.

The ATN depends upon three functional components:

ATN End Systems (ES)

End Systems contain all seven OSI layers in their protocol stack. This provides the ATN End System with the capability to communicate with other End Systems to provide end-to-end communication services.

Subnetworks (Ground/Ground and Air/Ground)

A subnetwork is an independent communications network based on a particular communication technology which is used to physically transfer information between attached end systems.

ATN Routers

Routers are intermediate systems (IS) and contain the lowest three OSI layers in their protocol stack. The router provides the connectivity between the various subnetworks and routes messages across the appropriate subnetworks based on criteria such as priority and Quality of Service (QoS).

 

3.2 The Security Concept of the ATN

The ATN makes use of a hybrid public key cryptography and symmetric cryptography because of the bandwidth constraints in transmitting data. For the public key cryptosystem elliptic curve cryptography was selected because it offers minimal bandwidth requirements (see chapter 4.4.1 "key length"). The symmetric branch is implemented using the MAC (message authentication code) scheme HMAC (Keyed-Hashing for Message Authentication, see chapter 2.5.3 for details). ATN end systems, intermediate systems and supporting certificate authorities (CA‘s) are using the characteristic 2 finite field (F2m) containing 2m elements.

 

3.2.1 Application Security Solution

The primary purpose of application security in the ATN is to ensure the authenticity of important air-ground communications. Each aircraft runs several applications which require secure communication with the ground control station. In the ATN there are a number of different applications, such as context manager application (CMA) or CPDLC (Controller/Pilot Data Link Communications) application. CPDLC provides the means for digital data communications between air traffic controllers and pilots. The ATN is organized in domains, such as nation or region-wide domains. Whenever an airplane begins a flight or enters a new CM (Context Manager) domain it performs a CMA Login, which consists of an authenticated key establishment protocol carried out by the aircraft CMA and the ground CMA. The protocol is based on the Elliptic Curve Diffie-Hellman protocol, which is an elliptic curve equivalent to the standard Diffie-Hellman algorithm (see chapter 2.2.2.3.1 "Method of Diffie-Hellman"). Three services will be provided when performing this protocol:

  1. the identities of the communication parties are confirmed
  2. a session key is established, which will be used to authenticate CMA dialogues
  3. a shared public value is established, which will be used to help securing other applications while the aircraft is in the domain.

After successfully logged in the first or new CM domain, CMA messages are secured using the MAC scheme HMAC with the session key to ensure their authenticity. A further session key is generated whenever an application within the domain wants to communicate with an application in the aircraft. This session key is calculated from the aircraft key pair, the application key pair and the shared public value (which is the one established during CM_Logon). For the message exchange again HMAC is used.

In order to operate this application security solution, each aircraft and each ground application must be provisioned with the requisite elliptic curve key pairs, and a Public Key Infrastructure (PKI) must to put in place to distribute public keys.

 

3.2.2 Public-Key Infrastructure

This section describes the ATN PKI architecture and what role each entity plays in it.


Figure 3-1: ATN PKI Architecture

The ATN includes mechanisms to provide security for application and routing related communications within the ATN. The security solution uses public key cryptography. The public key infrastructure provides the requisite support to distribute the public keys of ATN entities and therefore enable the operation of the ATN security solutions.

Figure 3-1 shows ATN entities that are on different levels of responsibility. The ICAO (International Civil Aviation Organization) has overall control of the ATN PKI. It specifies how the PKI operates. ICAO governs the States, who in turn govern the ground application entities, ground routers, and aircraft operating entities within their domain.

States govern the ground application entities, ground routers, and aircraft operating entities within their domain. They ensure and facilitate the effective and secure operation of the ATN PKI within their domain.

They assign entities which are called State Certificate Authorities (State CAs) to act as the certificate authority for the domain. Furthermore the state must put in place logical entities known as certificates. These certificates are used to clearly identify an entity one level lower.

State CA's provide certificates for Aircraft Operating Entities (AOE), Ground CMA Entities or other Ground Application Entities, Ground or Aircraft Routers and Aircraft Application Entities.

The certificates and the Certificate Revocation Lists (CRLs) provided by the entities have a special format that depends on the applications which are running during a communication. These formats are not described here, for more details refer to the ATN document "Public Key Infrastructure for the Aeronautical Telecommunications Network"55.

 

3.2.3 Cryptographic Details

The ATN security services are based on the elliptic curve digital signature algorithm (ECDSA, see chapter 2.7.10), the elliptic curve Diffie-Hellman Algorithm (key agreement) and the Keyed Hashing Message Authentication Code (HMAC, see chapter 2.5.3). The ATN PKI is based on the X.509 authentication framework.

 

CM_Logon


Figure 3-2: CM_Logon protocol

 

CM_Logon is an air-initiated protocol that is used to establish communications with the first Context Manager domain that the aircraft enters, and which may also be used to setup communications with second and subsequent CM domains. This protocol is performed each time an aircraft begins a flight or enters a new CM domain. First the aircraft (A/C) sends a logon request (CM_Logon_req). This request contains the aircraft's signature using the private key with 163 bits. Furthermore 46 octets are added to this signing message (step 1).

In the steps 2 to 4 the bandwidth limitations do not play an important role, since communication is not required between aircraft and a ground control station. The context manager sends a certificate request to the Certificate Authority (see chapter 3.2.2 "public key infrastructure"). The certificates are sent back from the Certificate Directory to the Context Manager. CM checks the certificates and generates the shared value which is used to ensure secure communication between ground and air applications and the MAC (message authentication code) key for the symmetric communication. Then, the context manager sends his HMAC to the aircraft (32 bits in size), his public key (125 octets) and the applications public keys (168 bits for each).

The shared secret value is valuable as long as the aircraft is in the domain.

With all overhead the CM_Logon has to transmit in total 1637 bits if the keys of two applications are transmitted.

IDRP_Exchange


Figure 3-3: IDRP_Exchange protocol

 

The IDRP_Exchange protocol transmits information between the Aircraft Router and the Ground Router. This protocol works at level 3 of the OSI reference model. It is used for the secure exchange of routing information between ATN Intermediate systems.

First the aircraft and the ground router exchange the ISH PDU (Intermediate System Hello Protocol Data Unit) to authenticate each other. The ground router sends a certificate request to the certificate directory and receives the aircraft's public key certificate.

Then the IDRP_Open-PDUs are exchanged. The Open-PDU is used by a BIS for starting a BIS-BIS connection. A BIS is a Boundary Intermediate System (or border router). All IDRP information is carried between a pair of BISs in the form of BISPDUs.

The first PDU which is sent by either side is an OPEN-PDU. The Open-PDU contains the authentication code type 2 field (1 octet) and the authentication data, which is in the ATN context the public key and has variable length. Authentication code 2 indicates peer-BIS authentication. Data integrity is ensured for the contents of the BISPDU.

An UPDATE-PDU is used to advertise feasible routes to a neighbor BIS, or to withdraw multiple unfeasible routes from service. The IDRP_UPDATE-PDU contains a 10 octet HMAC to tag subsequent BISPDUs.