Aerospace and Electronic Systems Magazine November 2017 - 26

Datalink Security in LDACS for Air Traffic Management
Objective 4 is given only with a "should." This is mainly because the potential safety impact of eavesdropping on air traffic
management services has been assessed with lower severity. Furthermore, safety risks may occur when an aeronautical stakeholder
is not able to decrypt air traffic management data. Besides this, the
current ICAO policy prevents end-to-end encryption of air traffic service communications ([32], pages 8-14) implying that the
application of encryption mechanisms may be restricted in some
cases [34], [36].
The following classes of functional security requirements are
derived to cover the security objectives defined above [34], [35]:
C

F_Audit: Security audit, i.e., recognizing, recording, storing, and analyzing information related to security-relevant
activities
F_Auth: Identification and authentication, functioning to
establish and verify attributes, e.g., the identity claimed by
an entity
F_Crypto: Cryptographic support using cryptographic functionality to help satisfy several security objectives
F_Data: Data protection policies and mechanisms for access
control and information flow control inside a device
F_Robust: Robustness support based on physical layer functionality

F_SecFunc: Protection of the security system functionality
(related to the integrity and the management of the mechanisms that constitute the security system functionality)
Table 1 shows which security objectives are addressed by the
listed functional security requirements.
C

LDACS SECURITY IMPLEMENTATION OPTIONS
The first step in adding security functionality to LDACS is to
analyze possible options to implement the identified security
functions within the existing system architecture. We restrict
ourselves to options that can be added to the existing protocol
specification. A design process from scratch might yield different
results but is outside the scope of this article. In this section, we
investigate implementation options at several points within the
LDACS protocol stack. In addition, we discuss the implications
of these options.
Security is not free and requires the dedication of resources to
its purpose. The second step in the analysis is thus to map the most
resource efficient option (in terms of resilience and overhead) that
fulfills all requirements for the LDACS protocol stack. This step is
carried out in the next sections.

SECURITY IN THE PHYSICAL LAYER
According to resolution 417 of the World Radiocommunication
Conference in 2007 [37] modified in 2012 [38], the frequency
band 960-1,126 MHz is conditionally allocated to LDACS on a
secondary basis. The primary user of this frequency band is the
DME radio navigation system.
26

Table 1.

Security Objectives and Functional Security
Requirements
Security Objectives

Functional Security
Requirements Addressing
the Objective

Objective 1: Safety and
efficiency

F_SecFunc, F_Data

Objective 2: Reliability
and robustness

F_Robust, F_SecFunc

Objective 3: Message
authentication and
integrity

F_Crypto, F_Auth

Objective 4:
Confidentiality

F_Crypto, F_Data

Objective 5: Entity
authentication

F_Crypto, F_Auth

NOTE: These requirements are not necessarily disjointed.
Some requirements imply others; e.g., authentication (F_Auth)
requires cryptographic support (F_Crypto). In addition,
Objective 2 (robustness against denial of service) and the
derived functional security requirement F_Robust cannot be
provided by cybersecurity means alone. Additional security
(noncybersecurity) means will be required in a comprehensive
security concept for LDACS.

LDACS will be deployed in an inlay approach between
DME channels. Inlay deployment foresees LDACS channels (500-kHz bandwidth) being deployed between neighboring DME channels (1-MHz spacing) [31], as illustrated in
Figure 3a. If larger gaps between DME channels are available,
they are preferred. The feasibility of the inlay approach has
been demonstrated in flight experiments as shown in Figures
3b and 3c [39], [40].
The specification of the LDACS physical layer is publicly
available [15]. This may enable malicious attacks targeting specific features of the system [41]. Attacks on the physical layer aim
to disrupt communication between authorized entities. In their
simplest form, they aim to increase the noise floor at the receiver and to degrade the signal-to-noise ratio. The consequence is a
denial-of-service attack increasing bit, symbol, and packet error
rates and hence limiting the throughput of the datalink or causing a
temporary loss of connection.
Although the setup of aeronautical infrastructure (cordoned-off
airports and flying aircraft, with high security standards and uptilted antennas) makes interfering with the LDACS signal difficult,
additional robustness against denial of service is desirable.
LDACS can be made more robust in the physical layer by one
or more of the following approaches:
C

Increased transmission power: Although power inefficient, including margins in the link budget calculations of
LDACS would help to make the signal more robust against
interference.

IEEE A&E SYSTEMS MAGAZINE

NOVEMBER 2017

Table of Contents for the Digital Edition of Aerospace and Electronic Systems Magazine November 2017