ADS-B Authentication HTT Consulting
Oak Park MI 48237 USA rgm@labs.htt-consult.com
Bastionnage Consulting
Montreal Canada jose.fernandez@bastionnage.ca
Polytechnique Montréal
Montreal Canada mikaela-stephanie-2.ngamboe-mvogo@polymtl.ca
AX Enterprize, LLC
4947 Commercial Drive Yorkville NY 13495 USA stu.card@axenterprize.com
AX Enterprize
4947 Commercial Drive Yorkville NY 13495 USA adam.wiethuechter@axenterprize.com
sec TBD RFC Request for Comments I-D Internet-Draft TESLA ADS-B The Automatic Dependent Surveillance – Broadcast (ADS-B) is a surveillance technology mandated in many airspaces. It is now widely deployed but suffers a lack of security and privacy. From a security point of view, it is relatively easy to spoof the ADS-B messages. With the appropriate readily available hardware and software. From a privacy point of view, all the messages contain the aircraft’s assigned 24-bit ICAO address, which makes it easy to link to data about the aircraft, in particular to know when a particular aircraft has flown and where to. In addition, the main transmission medium utilized for ADS-B, i.e. the 1090 MHz frequency used by Extended Squitter (1090ES), is approaching saturation in some parts of the world with ADS-B and other protocol messages, resulting in packet loss in certain areas . This paper presents the IETF TESLA protocol along with X.509 certificates issued by ICAO member states for each aircraft to authenticate all ADS-B messaging. It leverages the 8PSK phase overlay (PO) scheme proposed in the Minimum Operational Performance Standards (MOPS) for ADS-B (RTCA ), which enables 1090ES ADS-B transmissions to convey three times more information, to support the transmission of the extra security information required by the authentication scheme. By doing so, the impact of authentication on channel usage is negligible. Beyond message authentication, this scheme protocol has two important additional benefits: 1) the possibility to implement a Flight Authorization scheme, allowing ATC and intercepting aircraft to not only authenticate an aircraft but to verify that it is authorizes to conduct that flight and 2) a methodology for adequately protecting the privacy by assigning rotating 24-bit identifiers to designated aircraft, while maintaining the possibility to (blindly) authenticate their ADS-B transmissions.
Introduction
Problem statement The Automatic Dependent Surveillance – Broadcast (ADS-B) technology is an aviation surveillance protocol that periodically broadcasts the aircraft’s position and other related data, enabling the aircraft to be tracked. ADS-B does not require an interrogation signal from the ground or from other aircraft to activate its transmissions. ADS-B can also function point-to-point with other nearby ADS-B equipped aircraft to provide traffic situational awareness and support self-separation. ADS-B messaging is subject to spoofing attacks with readily available hardware and software, an important security threat. In addition, it exposes potentially confidential information about the aircraft, which is problematic for general and business aviation (i.e. disclosure of Personally Identifiable Information (PII) such as itinerary), as well as military aircraft (disclosure of classified flight trajectories). Both the security and the privacy threats are recognized to have an impact on aviation safety and need to be addressed. Another problem, unrelated to ADS-B, is the difficulty for Air Traffic Control (ATC) or a military air force to quickly ensure that a given aircraft approaching restricted airspace (e.g. Temporary Flight Restriction (TFR) zones, or Air Defense Identification Zone (ADIZ)) is indeed authorized to fly through that airspace. Current solutions rely on the cross-verification of flight authorizations issued prior to the flight (e.g. flight plan, authorization code) with immediate aircraft identification through transponder code or other visual means. This is problematic and can lead to potentially dangerous situations, especially in zones of conflict or during emergency situations (e.g. ESCAT, ATC Zero).
Protocol Overview This protocol provides an authentication augmentation to ADS-B.
    1. It effectively prevents spoofing attacks by providing a means to verify the authenticity and origin of each ADS-B message.
    2. Optionally, it allows for the off-line verification of flight authorization for airborne aircraft, from ADS-B transmissions alone.
    3. It retransmits an ADS-B message via the next message’s Phase Overlay, increasing the probability of content reception.
    4. It provides an optional mechanism to eliminate the transmission of sensitive information that might lead to undesired disclosure of PII (general and business aviation) or classified information (military aviation).
The protocol uses TESLA to provide message origin authentication, while it relies on the use of Public-Key Infrastructure (PKI) to provide sender identity (entity) authentication. In the overall process, identity authentication (using certificates and signatures) is performed to verify that the sender is who they claim to be. The challenge presented by needing a very large namespace for globally unique identities is provided by using the IETF DRIP Entity Tag (DET) . DETs are much more than an extremely large namespace for aviation. They are condensed Identifiers for the Entity certificate and its verifying certificate chain to a trusted root. These condensed Identifiers can fit within the additional data capacity enabled by Phase Overlay (PO) mechanisms, whereas even the smallest purpose-built certificate can’t. They then function as a reference to the full certificates needed for authentication. Their embedded trust hierarchy provides the needed management connection for such a namespace. With the sender’s identity established, TESLA is used to ensure that the received messages were indeed generated by that sender and have not been forged. This is done by having the transponder sign the TESLA “Key Anchor”, K0 (), for a particular flight. The Air Navigation Service Provider (ANSP) can also sign the TESLA key anchor, which provides a means to verify flight authorization, i.e. that the aircraft is authorized to fly at that time and in that airspace. Optionally, the confidentiality problem can also be handled by replacing the fixed 24-bit aircraft address with a 24-bit identifier different for every flight that only authorized organizations can resolve to the underlying identifier. This is similar to the FAA Privacy ICAO Address program, except that the protocol supports a different identifier for every flight. Our protocol relies on the use of the 8PSK Phase Overlay (PO) modulation proposed in the Minimum Operational Performance Standards (MOPS) for 1090 MHz Extended Squitter (1090ES) ADS-B (RTCA DO-260C ). We do this to minimize the impact of message authentication and entity authentication on 1090ES channel use. This protocol herewith builds on the Compatible Authenticated Bandwidth-efficient Broadcast protocol for ADS-B (CABBA) proposal published in March 2025 . It provides additional detail on implementation with the DO-260C standard and how to implement the PKI based on the Drone Remote Identification Protocol (DRIP) standard .
The new ADS-B Protocol Data Unit In ISO networking stack terms, the new RTCA DO-260C 8PSK PO is not a separate data unit, but an expansion of the base 1090ES pulse position modulation (PPM). The PPM portion provides data source information for receivers via:
    • Downlink Format (DF, how the PPM is formatted)
    • Device Address (24AA)
    • Type Code (TC)
The PO portion will extend the PPM with additional (204 bits) data capacity. This protocol uses DF of 17 and 18. For DF=17 and DF=18 with CF=0, the address field is the ICAO 24-bit Aircraft Address. For DF=18 with CF=1, the address field is an unstructured (i.e. anonymous/random) 24-bit address. The Type Code only applies to the PPM Message. The PO portion will need its own Message Type (MT, see below). As this protocol is authentication for ADS-B, the principal content in the PO is the TESLA MAC and supporting data. It will be shown that minimally, a packet counter is needed along with the TESLA MAC and a timestamp provides additional functionality beyond a counter. Thus, MOST PO message content will be:
    • Message Type (MT, 8 bits)
    • Timestamp (24 bits)
    • TESLA MAC (28 bits)
Thus 144 bits remain for data content. The content options will be defined below. There are some special, large, messages that exceed this 144 bits and are public key signed, thus internally authenticated. These messages either use the full 196 bits (left after the MT) or the proposed “Extended” messaging with the 51 bits of the PPM ME (via a unique “Extended” TC) for 247 bits. These messages will also be defined further down.
Reduced transmission power for short-range use cases FAA Advisory Circular (AC) 20-165B for the 1090ES link requires 125 watts minimum transmit power at the antenna output which equates to 40 Nautical Miles (NM) range (RTCA DO-260C standard transmit power). Power is often up to 200 watts for commercial Mode-S transponders and a 90 NM range. These power levels can result in significant channel over-use in busy airspace. A lower power level may be a better approach for ground systems, AAM, and air-to-air applications. DO-260C does provide for 70 W (range 10NM). A Mitre report from 2017 on ADS-B Performance with Small UAS at Low Altitudes shows that 25 watts (3-5 NM) is a good choice for these use cases. This lower power level may make ADS-B battery-powered devices more practical. An example might be a visor-clipped unit for “visiting” vehicles. With this proposed authentication feature, ATC would be assured as to what vehicle was showing on their system. As this protocol is authentication for ADS-B, the principal content in the PO is the TESLA MAC and supporting data. It will be shown that minimally, a packet counter is needed along with the TESLA MAC and a timestamp provides additional functionality beyond a counter. Thus, MOST PO message content will be: Although the lower power level will not decrease channel usage around these new participating group vehicles, with proper range limits will not impact approaching aircraft before final decent. In air-to-air use, the lower power may enable reception of the multi-frame Signed Key Disclosure and Compact Signed Token messages, but this will need testing. In AAM, the lower power could make it practical for ADS-B use, again for air-to-air.
Terms and Definitions
Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
||
Signifies concatenation of information (e.g., X || Y is the concatenation of X with Y).
Ltrunc (x, K)
Denotes the lowest order K bits of the input x.
Definitions
EUROCAE
European Organisation for Civil Aviation Equipment. Aviation SDO, originally European, now with broader membership. Cooperates extensively with RTCA.
CAA
Civil Aviation Authority of a regulatory jurisdiction. Often so named, but other examples include the United States Federal Aviation Administration (FAA) and the Japan Civil Aviation Bureau.
DET
DRIP Entity Tags (DETs) are a specific type of Hierarchical Host Identit Tags (HHIT) as defined in .
HDA (HHIT Domain Authority):
The 14-bit field in a DET that identifies the HHIT Domain Authority under a Registered Assigning Authority (RAA).
ICAO
International Civil Aviation Organization. A specialized agency of the United Nations that develops and harmonizes international standards relating to aviation.
RAA (Registered Assigning Authority):
The 14-bit field in a DET identifying the business or organization that manages a registry of HDAs. RAAs are typically allocated to CAAs as in .
RTCA
Radio Technical Commission for Aeronautics. US aviation SDO. Cooperates extensively with EUROCAE.
Safety
"The state in which risks associated with aviation activities, related to, or in direct support of the operation of aircraft, are reduced and controlled to an acceptable level" (from Annex 19 of the Chicago Convention, quoted in ).
Security
"Safeguarding civil aviation against acts of unlawful interference" (from Annex 17 of the Chicago Convention, quoted in ).
ADS-B Authentication Protocol Mechanism This paper presents a framework to secure ADS-B communications. It uses X.509 certificates issued within a state-managed PKI for identity authentication and TESLA for message origin authentication. The RTCA 8PSK phase overlay is leveraged to convey additional data within 1090ES transmissions with minimal communication overhead.
Protocol Sketch The solution operates in two mechanisms:
    1. Message origin authentication
    2. Identity authentication
Message Origin Authentication The ADS-B messages are authenticated using TESLA with a 28-bit TESLA MAC carried in the PO. The processing is as follows: At the Sender
    1. The PPM and PO payloads are built with the MAC set to ZERO.
    2. The MAC is calculated over the full 112 bits of the PPM and the first 216 bits of the PO (PO less Parity Correction Data) with the MAC field set to ZERO.
    3. Insert the MAC into the payload.
    4. Apply RS/LDPC encoding.
    5. Transmit.
At the Receiver
    1. FEC Decode.
    2. Verify MAC (after Key Disclosure below).
Note that the MAC is generated using a TESLA interval key known only to the sender at the time of transmission. This key evolves at fixed intervals according to a predetermined key chain. The interval key is disclosed after a short delay, ensuring that the messages and the MAC are received before the key becomes available, thereby preventing real-time forgery. Upon key disclosure, the receiver performs two checks:
    1. It verifies that the newly disclosed interval key is valid, by checking that it belongs to the same key chain as previously disclosed keys, hence ensuring that it was sent by the same sender.
    2. It computes the MAC of messages received in the previous interval with the newly disclosed key, and compares it with the received MAC, to verify that the corresponding group of messages covered by those MAC originate from the key’s owner and have not been altered in transit.
Sender Identity Authentication Each aircraft transmitter is provisioned with a cryptographic key pair and an X.509 certificate issued by its operator (or ANSP or CAA) within a state-managed PKI. The certificate binds the aircraft’s 24-bit address (ICAO or anonymous) to a DRIP Entity Tag (DET ), enabling receivers to verify that the sender controls the corresponding private key. A signed “token”, extracted from the certificate is periodically broadcast to support real-time, over the air, validation. This token is designed to provide the cryptographic proofs needed by receivers, yet fit within the ADS-B transmission constants. Alternatively, the certificates can be cached or pre-loaded by the receiver which obviates the need to broadcast the tokens often (this will be discussed further in ). This step authenticates the sender’s identity but does not guarantee alone the integrity or authenticity of the ADS-B messages it transmits. Note, receivers having access to the certificate validation chain is a separate problem. In many cases they may be cached in the receiver, or using their DETs, retrieved via DNS. Over-the-air transmission of these certificates for air-to-air use cases are not covered here. While TESLA ensures message origin authentication (two messages come from the same sender because they were MACed with interval keys in the same key schedule), it does not ensure who that sender is. In order to bind a particular key schedule, and hence a sender, to an identity, it is necessary to periodically send a signed interval key. This key is signed by the aircraft and optionally also by an ANSP (flight authorization).
ADS-B Messaging This section describes the structure of ADS-B messages, focusing on the additional capability the PO adds to the baseline PPM messages. PO messages, introduced in MOPS DO-260C, allow additional information to be transmitted using the same PPM-modulated carrier. This additional information is encoded in the phase of said signal by applying 8PSK modulation. As a result, a single transmission can carry both a baseline ADS-B message and additional data, which may correspond to another ADS-B message or to other types of information. The PO capability enables the simultaneous use of both amplitude and phase domains. DO-260C treats PO as a new message. This protocol, however, treats it as expanded capacity to the baseline PPM message. This can be exploited in three main ways:
    1. to transmit independent and unrelated messages in each domain
    2. to transmit related information, such as a message together with its associated authentication data (e.g., MAC, signature, certificate)
    3. to extend a single message by distributing its content across both domains
Baseline Message The current, “baseline”, ADS-B datagram is 112 bits of which only 51 are for message data. As noted, this is either DF=17 or DF=18 with CF={0,1}. This 51-bit message is identified by an ICAO 24-bit aircraft address or 24-bit random address (herein referred to as 24AA) and a 5-bit Message Type Code (TC).
ADS-B baseline message DF=17 & 18 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 DF=17 CA 24AA TC MSG CRC CRC 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 DF=18 CF 24AA TC MSG CRC CRC
Phase Overlay Messages In 2020, RTCA proposed the use of Phase Overlay (PO) encoding for ADS-B in 1090ES . The phase shift keying schemed proposed was 8PSK, which allows for 3 bits encoded in phase in each 1 µs pulse encoding 1 bit of the baseline signal. The alternate scheme 16PSK has been proposed by some researchers, but was not retained in the MOPS. While 16PSK has greater spectral efficiency than 8PSK, preliminary analysis of Bit Error Rate (BER) in typical ADS-B use-case scenarios , indicates that the BER using 16PSK would be too high. In the rest of this paper, we therefore propose and use 8PSK as mandated in the MOPS. The PPM packets consist of 112 pulses, encoding 112 bits, with a total duration of 112 µs; with 8PSK PO additional 336 bits can be sent during that same period. However, as depicted in , there is a 12-bit Reference Synchronization Phase (Sync) and 120-bit Parity Correction which leaves only 204 bits for data. From which the first 8 bits are for the Message Type field (MT) leaving 196 bits for actual message content. With the 24-bit Timestamp and 28-bit TELSA MAC, there remains 144 bits for message content.
ADS-B Phase Overlay (PO) message with Authentication including TESLA MAC 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Sync MT MSG TS Timestamp TESLA MAC MAC Parity Correction
RTCA in DO-260C, and perhaps other entities, are providing PO-specific messages that are more efficient than the baseline messages they replace. Support of these messages require changes in the ADS-B application both in the sender and receiver. The new PO message from RTCA, and potentially other entities, present a challenge if they do not allow for the TESLA MAC. For this protocol, ALL PO messages (other than the TESLA specific messages below) MUST have the 28-bit TESLA MAC and should have the 24-bit timestamp . As illustrated in , this leaves 144 bits for content (more than two 56-bit legacy baseline messages). The current (baseline) and the new PO ADS-B messaging do NOT include any message ordering content (e.g. no Sequence Number or Timestamp). Due to the ADS-B rebroadcast (ADS-R) and space-based ADS-B feature to enlarge coverage area, receivers MUST expect duplication and out-of-order packet delivery. This has significant impact on the authentication approach used herein. The addition of a timestamp as shown in , above, is highly recommended for all new PO messages.
ADS-B Authentication This section describes the mechanisms used to authenticate ADS-B messages, including data origin authentication using TESLA and sender identity authentication using digital certificates managed by PKI.
The Timestamp TESLA needs packet ordering, at least within the TESLA key interval. ADS-B practically assures out-of-order delivery. Here a timestamp with a degree of accuracy, within the TESLA key interval, is used to clearly tag messages associated with a particular TESLA key. A counter could also provide this functionality, but a timestamp can have other uses within the ADS-B system and thus used. A 24-bit unsigned timestamp is used. At one-second resolution, it provides approximately 194 days of coverage, slightly more than six months. The timestamp is therefore defined over consecutive six-month epochs beginning at 00:00 UTC on January 1 and July 1. The timestamp represents a continuous count of elapsed seconds from the start of the current epoch, analogous to GPS Time and International Atomic Time (TAI), and is not adjusted for leap seconds. Since leap seconds are inserted only at the end of June or December, coincident with the epoch boundaries, this definition inherently eliminates any one-second ambiguity at the epoch transition. The transmitted timestamp contains the elapsed time, in one-second intervals, from start of current epoch for the transmitter. Consequently, the receiver must reconstruct the complete timestamp by determining the appropriate six-month epoch. In normal operation, this reconstruction is straightforward. The receiver compares the received timestamp with its own synchronized UTC clock and selects the epoch that produces a reconstructed time closest to its current time. Since transponder and receiver clocks are expected to remain synchronized within a bounded tolerance, only one epoch will normally satisfy this condition. An ambiguity exists only during the brief interval surrounding the epoch rollover at 00:00 UTC on January 1 and July 1. During this period, a timestamp value could represent either the final seconds of the preceding epoch or the initial seconds of the new epoch. The receiver resolves this ambiguity by selecting the epoch that minimizes the difference between the reconstructed timestamp and its local clock. As a practical consequence, timestamp values near zero are interpreted as belonging to the new epoch, while values near the maximum count are interpreted as belonging to the preceding epoch. Because the maximum permissible clock offset between the transmitter and receiver is limited to a few hours, the ambiguity window is likewise limited to only a few hours on either side of the epoch boundary. Outside this narrow rollover interval, the reconstructed timestamp is unique, and the correct epoch is immediately determined without additional processing.
Authentication Technologies TESLA is the authentication technology used here. X.509 digital certificates, managed within a globally-scoped PKI (or Federated PKIs) provide the trust mechanism required by TESLA.
TESLA Basics Author's Note: This section is still missing some technical details. For example, KN itself is hashed to make the key used in the key MAC. The missing details will be added in later revisions. TESLA is a protocol that provides data origin authentication for broadcast and multicast messages. Each message carries a Keyed Message Authentication Code (Keyed MAC). The TESLA key used to generate the MAC is disclosed only after a short delay, allowing receivers to verify the authenticity of past messages while preventing forgeries. This delayed disclosure does create a window when messages are unauthenticated.
TESLA Key Chain Generation Before broadcasting, the sender divides the broadcast period into N equal time intervals and generates a one-way key chain of at least N+1 keys: one key for each interval and an additional key K0 that serves as a commitment or “anchor” for the entire chain. The key chain is generated as follows:
    1. Randomly choose the key for the last interval, KN.
    2. Compute the preceding keys and the commitment K0 by repeatedly applying a one-way function F to the next key in the chain:
Ki=F(Ki+1) for i=N-1,n-2,...,0
This produces the key chain in generation order:
KN -> KN-1 -> ... -> K1 -> K0
During message authentication, TESLA keys are used and disclosed in forward order:
K1 -> K2 -> ... -> KN
K0 is never used to generate MACs; it serves solely as a commitment, allowing the receiver to verify the authenticity of all TESLA keys. Once the key chain is generated, the sender securely communicates a key disclosure schedule to the receivers. This schedule specifies:
    • Interval duration Tint, broadcast start time ti, and total number of intervals N
    • Key disclosure delay d
    • Commitment to the key chain K0
Using this schedule, receivers can verify each disclosed TESLA key against the commitment K0, ensuring that all messages originate from the legitimate sender.
Message Transmission (Sender side) For each message mi transmitted during interval i, the sender performs the following steps:
  1. Derive the authentication key from the interval key Ki using a one-way function F:
Ki=F(Ki)
  1. Compute the MAC of the message using the derived key:
MACj=MACKi(mj)
  1. Construct the TESLA packet containing only the message and its MAC:
Pj=mj||MACKi(mj)
  1. Transmit the packet over the network.
The interval key (or TESLA key) Ki is disclosed only after a predefined delay d, so the receiver must temporarily store (or treat them as “authentication pending”) the received packets until the corresponding key is revealed.
Messages reception and authentication (Receiver side) Upon receiving TESLA packets, the receiver uses the time synchronization protocol to determine whether the TESLA key for the corresponding interval has been disclosed. If not, the packets are temporarily stored or flagged “authentication pending”. Once the TESLA key Ki-d for a past interval is disclosed the receiver:
  1. Verify the key’s authenticity against the chain commitment K0:
K0=Fv(Ki-d)
  1. Derive the authentication key for the interval:
K'i-d=F'(Ki-d)
  1. Recompute the MACs for all stored messages from interval i – d and compare them with the received MACs. A match confirms that the messages were indeed sent by the entity who generated the key chain and have not been altered.
TESLA in ADS-B Even with only 196 bits of message in each PO frame, the ADS-B TESLA MAC can follow the TESLA RFC with the MAC as part of the message ( above). It is not necessary to follow the TESLA design done for GNSS SBAS (Global Navigation Satellite System, Satellite-Based Augmentation Systems) Authentication, i.e. with the MAC is in a separate frame. TESLA uses a keyed-hash function to start the hash-chain construction and then a hash function to build the hash-chain and for receivers to authenticate disclosed Kn back to K0. Further, TESLA uses a keyed-hash to MAC messages with the currently undisclosed Kn and for receivers to authenticate these messages after Kn is disclosed and authenticated back to K0 (or the last authenticated disclosed Key). For the TESLA hash-chain and MAC, cSHAKE128 and KMAC128 are recommended for their lower timing operation over a truncated HMAC (2 SHA operations compared to one sponge SHA3 operation). ASCON-CXOF128 and ASCON-KMAC128 are a more efficient choice to use here. ASCON is specially designed for applications like ADS-B Authentication. Note that an ASCON-KMAC is not specifically provided in NIST SP800-232, but it is a direct function of CXOF. Thus, this being “greenfield”, ASCON should be given serious consideration over even cSHAKE/KMAC. PQC Notes: for the longer symmetric keys for PQC, cSHAKE256 and KMAC256 should be used. Further, ASCON is not PQC ready. ASCON was specifically designed for 128 bit keys which are considered too short against QC attacks. There is the ASCON-80pq variant with 160 bit keys. But this may still be considered too small a key. This remains an open issue with ASCON and may be the issue that directs the use of KMAC. For authenticating the TESLA hash-chain, EdDSA25519 X.509 certificates are used here. This provides the smallest, NIST-approved, signature (64 bytes) and public key (32 bytes) available. ”raw” encoding of key fields of the X.509 certificates are used to reduce the signing certificate size for in-band transmissions (what amounts to a signed token, rather than classic “certificate”). At this writing, it is unclear which Post-Quantum Cryptography (PQC) algorithms will fit within the current ADS-B messaging constraints. None of the current approved PQC algorithms are workable within these constraints.
Authentication Messages Four PO payloads are used with ADS-B Authentication. The four messages are:
    • Just MAC
      • This message’s 144-bit content area is ZERO. It provides authentication for the PPM portion.
    • PPM Resiliency 1
      • The 56-bit ME from the prior transmission is included to increase likelihood of reception.
    • PPM Resiliency 2
      • The 56-bit ME from the prior two transmission is included to increase likelihood of reception.
    • DET
      • The DET associated with the transmitting device. For out-of-band retrieval of the TESLA Signed Key Disclosure and Compact Signed Token.
There is one PO payload without the ADS-B TELSA Authentication. It does not need the TESLA Authentication, as it has its own Authentication mechanism. The message is:
    • TESLA Unsigned Key Disclosure
      • The TESLA key to authenticate the messages for the current interval. This is the last message for that interval, though actually sent in the next interval.
As will be discussed this protocol should send this with TESLA Authentication. This is to authenticate the PPM content. For the, larger, PQC keys, the timestamp and MAC are dropped, leaving authentication of the PPM content to a following Resiliency messages. Finally there are two messages that establish the trust binding between the TESLA hash-chain and the PKI Entity trust world.
    • TESLA Signed Key Disclosure
      • The TESLA key, along with other data, signed by the Entities PKI key.
    • Compact Signed Token
      • A minimal X.509 content token to validate the TESLA Signed Key Disclosure.
These messages exceed the capacity of a single PO payload, as they contain Public Key signatures plus other large datum. They do not need to be TESLA MAC signed, nor timestamp. They are still too large for a single payload and would have to be spread across multiple PPM frames. Given the DET, a receiver with Internet connectivity should be able to retrieve them from DNS per . It is only for air-to-air (and non-connected ground receivers) that need these messages. This will be detailed further in this protocol. It is this critical addition in the 128-bit DET in the TESLA messaging, above. It is the DET that provides the linkage to the full certificates (and situations where in-band certificate transmission is not possible or not needed) and the trustworthy identifier for use in back-end systems. It is the inclusion of the DET that provides the trustworthy indirection to safely remove the PII-revealing 24AA, i.e. the possibility of replacing a fixed 24AA with a randomized per-flight 24AA. For receivers with DNS lookup access, the DET can be used directly to get the Compact Signed Token. It is possible to even get the K0 TESLA Signed Key Disclosure via DNS as well. This is especially valuable in congested channel situations where these multi-frame messages may be lost. The TESLA parameters include:
    1. Interval duration
    2. Unsigned key disclosure frequency
    3. TESLA key size in bytes
    4. TESLA keyed MAC algorithm
The ADS-B TESLA parameters further include:
    1. Signed key disclosure frequency (note: not all interval keys must necessarily be signed)
    2. in-band certificate transmission frequency
For per-flight certificates (i.e. for privacy or flight authorization purposes), the Certificate Validity Dates provides the Broadcast Start Time (Not Before Date) and total intervals N ((Not After Date – Not Before Date) / interval duration). Thus, only the TESLA key parameters are sent over the channel. Otherwise, for longer-lived certificates, e.g. those issued for individual aircraft by Civil Aviation Authorities (CAA), their distribution method can either be in-band or through other means (e.g. Internet-based PKI certificate lookup leveraging the DET). Note, for example, that if the interval duration is 5s and the flight is 20h, N=14400. The TESLA Broadcast Start Time (1 minute accuracy), and Total number of intervals (N) parameters are encoded in the Signed Key Disclosure messages, as they are specific to each authentication chain. For per-flight certificates, the following conditions must additionally be met:
    1. The Broadcast Start Time MUST be after the notBeforeTime in the certificate,
    2. The beginning of the last transmission interval MUST be before the notAfterTime in the certificate, however,
    3. The last transmission (i.e. Broadcast Start Time + N * interval duration) MAY be after notAfterTime in the certificate, but MUST be before notAfterTime + interval duration (or a at least fraction thereof).
For reference, the CABBA proposal explored the compromise between Channel Occupancy Rate (COR) and safety margins (in both ATC and airborne traffic awareness scenarios) for the following possible parameter values:
    1. Interval duration: 5 seconds
    2. Unsigned key disclosure frequency: every 5 seconds (every interval)
    3. Signed key disclosure frequency: every 5, 10, 15 seconds (every interval, every 2nd or 3rd interval)
    4. In-band signed token transmission: every 5, 15, 20 and 30 seconds (every interval, every 3rd, 4th or 5th interval)
All of these values provided limited overhead in terms of COR, while providing mostly adequate safety margins. Nonetheless, further analysis is required to determine adequate values for deployment in a new ADS-B standard. Note that there is ongoing discussions on the overhead of the Signed key disclosure, particularly with a PQ Signed key disclosure. At the start of a flight the transmitter starts using the Signed Key Disclosure message with a Start Time as close as possible to and before the current time. It discards any unused interval keys that are for a prior start time. The transmitter SHOULD send the Signed Key Disclosure messages at the start of flight and at some pre-determined frequency. The receivers may cache previously received batches of Signed Key Disclosure messages even before receiving any ADS-B messages or certificates for that transponder. For any Unsigned Key Disclosure message received there MAY be more than one possible Signed Key Disclosure message to consider, but only one will validate the Key, or the Key is fraudulent. The receiver may have multiple Signed Key Disclosures for a single 24AA with different Start Times. The transmitter may have distributed these in advance to cover the day’s flights. Thus when hashing an unsigned Key back to a Signed key, the receiver must check against all such Signed Keys. Once this unsigned Key is validated to a Signed Key, all Signed Keys with an earlier Start Time may be discarded. This caching authenticates previously received messages. The receivers (avionics and ground stations) should be appropriately engineered to support caching of multiple aircraft within the time window of interest (a few minutes for aircraft to fractions of an hour for ATC).
Just TESLA MAC within PO This message simply provides authentication for the PPM content. It is included more as an example. In practice, it is unlikely to be used. The PO Message Type of <JTM-TBD> is used.
Baseline messaging within PO – PPM Resiliency 1 This message resends the prior PPM’s 56-bit ME. By resending this ME, it increases the likelihood of its receipt. There are 88 bits unused. It will be future work on how new DO-260 work may use it. The PO Message Type of <PR1-TBD> is used. The message is as follows:
PO PPM Resiliency 1 message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Sync MT ME1 RESERVED Timestamp MAC TESLA MAC Parity Correction
The ADS-B transmitter determines the prior PPM message ME to transmit in the PO. On the receiver side, the prior ME is extracted from the PO. A full PPM message is constructed, and sent through the normal PPM processing path. There, it is either a duplication of the prior message, or provides the message that was lost from whatever event. The TESLA MAC is authenticated on receipt of the disclosed interval key. Below is an visualization of a 5 second stream (at 6.2 msg/sec) of the PPM Resiliency 1 messages (shown on the PO line as “1”) including an Unsigned Key Disclosure message (“U”) and DET message (“D”).
PPM Resiliency 1 message stream 0 1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 AM B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B PO 1 1 1 1 U 1 1 D 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
Note that the messages prior to U and D are not repeated. This can be addressed by using the PPM Resiliency 2 message following those messages.
Baseline messaging within PO – PPM Resiliency 2 A natural extension to the PPM Resiliency 1 message is the PPM Resiliency 2 message. Here the prior 2 PPM ME messages are resent. This leaves 32 bits reserved. The PO Message Type of <PR2-TBD> is used. The message is as follows:
PO PPM Resiliency 2 message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Sync MT ME1 ME2 RESERVED RSVD Timestamp MAC TESLA MAC Parity Correction
The Resiliency 2 message is constructed similar to the Resiliency 1 message, and likewise process similarly on the receiver’s side. The primary value in the Resiliency 2 message is to provide resiliency for the message prior to the one carrying Unsigned Key Disclosure or DET message. A transmitter may choose to always sent the Resiliency 2 over the Resiliency 1 message. Below is an visualization of a 5 second stream (at 6.2 msg/sec) of the Resiliency 2 messages (shown on the PO line as “2”) including an Unsigned Key Disclosure message (“U”) and DET message (“D”).
PPM Resiliency 2 message stream 0 1 2 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 AM B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B PO 2 2 2 2 U 2 2 D 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
The ADS-B DET Message The 128-bit DET is the indexing key to the Compact Signing Token, the K0 TESLA Signed Key Disclosure, and even the full X.509 certificate. It is carried in a TESLA MAC PO message to bind the DET to the TESLA chain and thus the 24AA so that receivers can trust that this is the DET to use for the DNS lookup (per ) of the appropriate certificate(s). The PO Message Type of <DET-TBD> is used. The message is as follows:
DET message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Sync MT DET RESERVED RSVD Timestamp MAC TESLA MAC Parity Correction
The ADS-B TESLA Unsigned Key Disclosure Message Author's Note: This section needs work. The larger, PQ key size was added after the original design for a 128-bit key. This needs clean up for better/clear support of larger key size for PQ. The TESLA Unsigned Key Disclosure is sent in one full PO message. It could be sent as the sole content in the 196-bit message as the current TESLA key (128 bits) with the rest of the message ZERO padded. The receiver validates this TESLA key by performing the TESLA Key hashing function until reaching the most current prior validated disclosed TESLA key. This MAY be K0, or a latter key Ki, obtained via a TESLA Signed Key Disclosure, or K0 obtained through another out-of-band authenticated channel. As this disclosed TESLA key is immediately hashed back to the last validated TESLA hash-point, there is no direct value in sending it in a TESLA MACed frame. However, doing so MACs the PPM content and thus this protocol actually sends Unsigned Key Disclosure in a MACed message identical (other than the MT) to the DET message ( above). One potential use of the Timestamp value in this message is to calculate which was the last message MACed with this key (time < This-Timestamp – Disclosure-Delay). Messages in “Validation Pending” status are divided into those prior to this time and SHOULD be authenticated with this key and those after this time and are still Pending (waiting for next Key). The TESLA Delay time, d, is important in that it needs to be long enough that an attacker cannot generate a spoofed message with an earlier time using the disclosed key. A delay time between 0.5 and 0.7 seconds should work to defeat this attack. Thus, the worst case is performing N hashes to K0. For example, with the proposed interval duration of 5s, a long 14-hour flight from Sydney AU to London UK may require close to 10,000 hash operations to verify the validity of the last interval keys. If signed keys are transmitted regularly, the number of hash computations would never be so high. For example, with the parameters explored in the CABBA paper , signed keys were sent at most at every 5th interval, thus limiting the number of hash computations to five. Nonetheless, a reasonable scenario where computation of the full hash chain for a flight would be required is where signed keys were never sent in-band but rather sent through another authenticated channel, e.g. in future PQC-compliant ADS-B Tesla implementations where signature sizes are to large to be sent in-band. In all cases, the use of the more efficient ASCON-CXOF128 over cSHAKE128 (or even less efficient HMAC) is preferable. There are operational approaches to receive prior authenticated TESLA keys, through other connections, to avoid this long hashing operation. Note that in the Post Quantum discussion below, a 192-bit TESLA key is recommended. This would take the whole available PO bits (196). Using all 196 bits (or even 160 bits) for the key would leave the PPM unauthenticated and thus requires the next message to be a Resiliency 1 (or 2) message. The PO Message Type of <UKD-TBD> is used.
The ADS-B TESLA Signed Key Disclosure Message The TESLA Signed Key Disclosure provides the trust of the TESLA hash-chain to a specific ADS-B transmitter. Initially, the key here is K0, which is never used in the MACing process. The first key used is K1. Thus, any prepublication of K0 does not compromise the TESLA authentication. If the regular transmission of signed keys is implemented, then transmitter may transmit a more “current” signed TESLA Ki key for a past i-th interval. Each such message will include 1) a Broadcast Start Time (format TBD), corresponding to the beginning of the interval of the signed key, and 2) the total number of intervals N, each 3 bytes. It may be more secure if this is the remaining number of intervals. This will require more study. If the signed key is NOT K0, it does not obviate the first sending of that key unsigned. The signed key ALWAYS comes after the sending the signed key. This message needs 5 full PO messages when the ADS-B Certificate Public Key algorithm is EdDSA25519. This message has a MT=<SKD>. The whole 810-bit message is:
    • Current TESLA key (128 bits)
    • DET of ADS-B signing certificate (128 bits)
    • Signature (512 bits)
    • TESLA Broadcast Start Time (24 bits)
    • TESLA Total number of intervals N (18 bits)
These 810 bits would need 5 PO messages, thus either using that many Message Types, or add a 3-bit subType field. The subType reduces the payload to 193 bits; this still fits into 5 messages. Note that compressing the DET to 94 bits (drop the prefix and limit the RAA to 8-bit range) does not reduce this to 4 PO messages. Plus, a PQC TESLA key of 192 bits pushes this message into a 5-frame requirement. The risk of dropping 1 out of 5 messages in ADS-B is real, thus a FEC message is recommended. If sent serially, these messages occupy the channel for 0.6 ms, where any other transmission could disrupt one or two messages. Thus, it is recommended that the transmitter use some strategy for ensuring complete reception of the 5-message set. The specific FEC algorithm is yet to be selected. See Appendix B for more discussions on FEC. It may well be that this Signed Key Disclosure message need only be sent once per minute or even less often, as discussed in the paper. It depends on how soon receivers need to identify the cryptographically true source of the messages. Note that the 24AA is in all ADS-B messages (in the PPM portion), but any sender can make any claim of a 24AA without this Signed Key Disclosure message or some other trusted published link of the TESLA K0 to the 24AA. For future asymmetric PostQuantumCrypto (PQC), a different Signed Key Disclosure needing more than 5 PO messages and a single FEC may not provide proper FEC behavior. This is a challenge to be addressed in future work.
The ADS-B TESLA Extended Signed Key Disclosure Message An important consequence Signed Key Disclosure message is the PPM content is NOT authenticated. These 5 (or 6 including a FEC frame) messages would have to be authenticated in a series of Resiliency 2 messages. This is a potential negative impact to sending the Signed Key Disclosure message. There is an alternate approach would create a new PPM message called “PO Extended” with a TC=<PO-Extended>. As this TC is unknown to existing ADS-B receivers, it will be ignored. The 51 bits from ME are used as extended bits to the 196 bits in the PO portion of the message, for a total availability of 247 bits. Even with the 3-bit subCode, the 810-bit Signed Key Disclosure message would fit into 4 frames. The PO Message Type of <SKD2-TBD> is used. With the 4th frame only having 75 bits of the message, there are design approaches that can limit the blocking of normal PPM messaging. For example only the first 2 segments are sent “Extended”. Then 2 segments of “regular” Signed Key Disclosure message segments. Those 2 PPM messages are authenticated by a following Resiliency 2 message. This calculation changes with a TESLA key of 192 bits. More research is needed to the most effective way to send the Signed Key Disclosure. The burst-mode (7 msg/sec potential) may be of value here to push out the 2 Extended PO messages, followed by the PO+PPM frames.
The ADS-B Compact Signed Token Each member State’s PKI may have different certificate content, making it challenging to work with. ADS-B certificates are more fully covered in . The inclusion of the DET addresses a common, hierarchical, identifier, but ALL these certificates will be too large to transmit in-band. For TESLA Signed Key Disclosure, only a few X.509 OIDs (Object Identifiers) from the certificates are actually needed. These are:
    • Certificate Validity Dates
    • ADS-B 24AA
    • ADS-B DET
    • Certificate Issuer DET
    • Certificate Public Key (note Algorithm is in SuiteID in DET)
    • Signature of these fields only by Issuer
These OIDs can be encoded as:
    • Certificate Validity Dates (32 bits)
    • ADS-B 24AA (24 bits)
    • ADS-B compressed DET (94 bits)
    • Certificate Issuer compressed DET (94 bits)
    • Certificate Public Key (note Algorithm is in SuiteID in DET) (256 bits)
    • Signature of these fields only by Issuer (512 bits)
Such an encoded object is 1012 bits; this is NOT X.509; it is more appropriately called a Signed Token. Thus “Token” will be used in all discussions of this object, to prevent confusion in that this is NOT a form of an X.509 certificate. Rather, it is an extraction of those X.509 OIDs that are needed for validating the TESLA Signed Key Disclosure. Following the payload formatting for the TESLA Signed Key Disclosure (sec 2.3) this would take 6 PO payloads, with MT=<CC-TBD>. Adding a FEC is recommended for a total of 7 payloads. Thus, the subType SHOULD be 4-bits. Even with the drop to 192 bits payload, this still fits into 7 PO messages. This expands considerably with any of the PQC algorithms. Note that with the DET, a receiver with Internet access can retrieve the full certificate as per .
The ADS-B Extended Compact Signed Token As with the Signed Key Disclosure message, this Compact Signed Token is challenging. The 7 PPM messages would have to be authenticated in a string following (or interlaced) Resiliency 2 messages. Here too, an Extended PO approach would be beneficial. Only 5 Extended messages (MT=<CC2>) would be needed. Also a mix of Extended and “regular” messages may be a valid approach. Further study is needed for the most effective transmission method.
ADS-B Certificates Author's note: PKI discussions will be in a separate ConOps document. The ADS-B Certificates follow the ICAO (sec 10.2.7, Aircraft Equipment Signature Certificate) ACCP with important additions. Each ADS-B transmitter’s certificate MUST contain these specific X.509 OIDs:
    • Aircraft DET in subjectAlternateName (SAN) as IPv6
    • Aircraft 24AA in SAN as IPv4 (with first octet of ZERO)
    • Issuer’s DET (CAA) in issuerAlternateName (IAN) as IPv6
      • Note that IAN is NOT included in the current version of 10169
Algorithms EdDSA25519 is the default algorithm based on its public key and signature sizes. Thus, at this time, transponder certificates MUST use EdDSA25519 and the issuing CA SHOULD use EdDSA25519. If the issuing CA does not (DOC 10169 calls for Ed448 for CAs), it will have no impact on the TESLA Signed Key Disclosure message but it will not be practical to send the transmitter Tokens in-band. Although ECDSA also has 64-byte signatures, support for the compressed 33-byte public keys is spotty (legacy of the Certicom patent ). This not only impacts cost of in-band certificate transmissions, but also storage costs for the 65-byte standard public key format. With the real concern over Quantum Computer attacks on ECC, the root and intermediate CAs should use some PQC algorithm. To maintain FIPS 140-3 compliance, DL-DSA or FN-DSA are preferred. DL-DSA HSMs are “in the pipeline” with FN-DSA lagging behind. However, FN-DSA is more attractive with its smaller sizes, based on the number of root and intermediate certificates a receiver may need to cache. One issue is that the math for FN-DSA signing is very complex and easy to get wrong. Any CA signing with FN-DSA MUST be developed and maintained by those that are able to deal with its implementation complexities. FN-DSA does not have this challenge in verification. For transponder certificates with PQC, the expectation is that one of the “NIST Additional Algorithms” will be available in time before “Q Day” and the ensuing rush. Even these have size challenges that may make in-band transmissions problematic for the Signed TESLA Key Disclosure, and impossible for even the Compact Signed Token. For example, SNOVA (37,17,2) has a 106-byte signature with reasonable" public key size of 9842 bytes. Thus, PQC at these levels of the PKI is an open issue. Note that at this time, there is no DET SuiteID PQC Algorithm assignments.
DETs for ADS-B The DET format is defined in ; it is a valid, though non-routable, IPv6 address. Amongst a number of advantages this provides, there is a well deployed distributed database via the DNS ip.arpa zone. Note the following discussion may change for any PQC TESLA Signed Key Disclosure. Following , RAAs 4048 – 5071 are allocated for ADS-B use. Each member State gets 4 RAAs assigned by an ICAO State numbering scheme (TBD). Each of these RAAs may have 163884 HDAs allocated per the State’s delegation process (For RAA, Registered Assigning Authority, and HDA, HHIT Domain Authority, in DETs see ). In practice, both the Intermediate CA and the Issuing CA have their own HDA value, so there are potentially fewer HDA-level entities, based on the State’s policies. For example, as the Intermediate level is long-lived, 64 entities, allocated 4 each HDAs to roll through over the years would each have 12 HDAs for rolling Issuing CAs. The details of this need further study. Each RAA and HDA MUST maintain their respective DNS zone in 3.0.0.1.0.0.2.ip6.arpa., per . This zone provides the global certificate retrieval database. It also may replace the CRL function. For all this DNSSEC is mandatory. This does present signing challenges at the HDA level. Further study is needed here. Is hourly signing, similar to timing for CRLs sufficient?
Implementation and Deployment Notes This protocol has two significant additions to the current ADS-B technology. It requires the new Phase Overlay. It adds cryptographic functions. Both of these require at least software updates on both transmitters and receivers. In some cases, new hardware will be needed. Thus, a phased-in approach is the only practical roll-out plan.
Impact on Transponders and Receivers – the Phase Overlay The team behind the CABBA proposal performed laboratory tests in collaboration with Collins Aerospace to test backward compatibility of this Phase Overlay approach. These tests involved sending the PO packets in D8PSK and making sure that that they did not interfere with legacy equipment reading and interpreting the 112 bits in the baseline signal. These tests were successfully tested against two different COTS ADS-B receivers (one certified, the other not). The question is how much would be involved for certified avionics manufacturers of ADS-B equipment (this would typically include transmitters, TCAS boxes, digital communication units, depending on the type/size of aircraft) to support the Phase Overlay in the MOPS. Our research is that most modern avionics use some kind of digital architecture (similar to software defined radios) where this could be achieved with a firmware upgrade, without adding new components. Many of them could be using FPGA to do the heavy lifting in terms of coding/decoding, and those could theoretically be reconfigured by a firmware update. That matters as it would influence the cost and speed of deployment of such a solution. As for old legacy equipment (e.g. General Aviation ADS-B transceivers and transmitters), we are most likely out of luck as encoding/decoding is probably hard coded in the hardware. Hence, the importance of having a backward compatible solution for the transition period.
Impact on Transponders and Receivers – Cryptography The transmitters are expected to generate their EdDSA25519 keypairs, and communicate the public key in an X.509 CSR during the flight plan submission process. The X.509 certificate is returned for storage in the transmitter. For key store, the transmitter should have an HSM; few do. To avoid requiring an immediate hardware replacement for implementation, the keys could be stored in secure memory (or such) and operate under ICAO doc 10169 Level Of Assurance (LOA) of 2 (Low Device). It may be possible to comply with LOA=5. The CAA may want to separate, for policy reasons those transmitters operating at LOA=2 and/or 5 from those with HSM and LOA of at least 9. This separation can be handled by using different HDAs. In addition to generating and using the EdDSA25519 keys, the transmitters will need to maintain the TESLA hash chain and use it in KMAC operations on the messages. This is additional storage and code. Some currently deployed units may be able to handle this in a software update. Future PQC requirements will most likely not be met with anything but the most recent hardware. This is a separate research issue.
Impact on Receivers – Cryptography Receivers will not be generating EdDSA25519 keying material nor signing messages. They do need to store many certificates and perform the EdDSA25519 and KMAC validations. For an Internet connected receiver, the storage requirement may be moderate. All certificates SHOULD be available via the DETs in a DNS lookup (reverse IPv6 retrieval). In a disconnected environment, the storage may be considerable. The FAA Aircraft test EdDSA25519 certificates with 600-800 bytes. There are potentially 1024 RAAs needing key rollover support. There are at least that many Intermediate HDAs and Issuing HDAs. Thus, planning should be upwards of 1024*3*1.5 = 55,296 certificates in a fully (every member State nonparticipating) situation. Further if a PQC algorithm is used at the RAA and Intermediate HDA levels to position for the anticipated PQ crypto world, those certificates will be considerably larger (may be a magnitude larger). This further confounds the memory needs.
A prudent deployment plan Any change to ADS-B will be disruptive. Airspace safety is best served by minimizing the disruption and spreading the changes out over time. With this change, however, the current Pulse Position Modulation and the new Phase Overlay can exist in the same time. A transmitter sends them simultaneously over the same pulses. A receiver decodes them from the same pulses. The two types of transmissions completely co-exist. This protocol specifies a 5 second TESLA Key disclosure. In those 5 seconds, 31 baseline messages may be sent (5 * 6.2). Higher transmission rates are now allowed beyond the original 6.2 messages/sec, including 6.4 messages/sec, and a burst-mode of 7 messages/sec. These higher transmission rates are not covered here. The TESLA authentication will send 1 unsigned key disclosure in that time interval (really the key for the prior interval, but still a disclosure). Those 31 baseline messages can be encoded in 16 Resiliency 2 messages. A transmitter can send the 31 baseline messages in 5 seconds and at the same time send the 17 PO messages, spread out over the 5 seconds with 14 “slots” empty. On day one, a transmitter that is PO-capable can immediately send both message types. Also ground receivers can start listening for, and use, PO messages and use their authentication to confirm proper receipt of the baseline messages (is there spoofing occurring?). At some point, a region will be fully deployed to monitor use of PO messaging. The region can monitor baseline messaging without PO and determine their course of action. The Transmitter may stop sending baseline messaging to reduce the channel congestion. This may impact air-to-air where the other aircraft cannot receive PO messages. There are immediate uses for some of those 14 empty slots. A FEC may be sent for the TESLA Key disclosure. The TESLA Signed Key disclosure can fit into one of the 5 second intervals in a 5-minute period as well as the compact token. Finally, at some point new PO messages will come out to replace use of the Resiliency 2, further reducing PO channel usage. Deploying ADS-B authentication comes at no channel utilization. As regions deploy reception of these messages and aircraft turn off their baseline messaging, overall channel utilization will decrease.
IANA Considerations There are no items for IANA in this protocol.
Security Considerations
TESLA MAC size TESLA has no advise on the size of the Keyed MAC. For the ADS-B Authentication protocol, a MAC size of 28 bits was selected as adequate and fits within the payload constraints of ADS-B. The key disclosure interval recommendation in this protocol is 5 seconds. With the ADS-B message transmission rate of 6.2 messages/second (recent revisions allow 6.4 msg/sec with "burst rate" of 7 msg/sec), the small number of messages protected by a single key (31 - 35 messages) is deemed to be too little to afford attackers with enough information to attack the MAC.
TESLA Key Disclosure timed attack A known attack with TESLA is to use a disclosed key to MAC messages and trick receivers into processing them as if they were sent prior to the disclosure. With a disclosure delay of 0.5 seconds proposed here, even the rebroadcast nature of ADS-B (via mechanisms like ADS-R) does not make it possible for a reasonably time synchronized receiver to erroneously accept a forged message. Any messages received after the key disclosure is expected (based on time since last disclosure) are either MAC with the next key in the hash-chain or are fraudulent. This does present a synchronization challenge for the first few time intervals observed by receivers.
PQC concerns for ADS-B Authentication None of the currently NIST-approved Post Quantum Cryptography (PQC) algorithms are possible to send over the ADS-B channel. The are just too big. This only impacts the Signed Key Disclosure and Compact Token messages. For ground-based receivers with Internet connectivity, this information could be gained using the DETs to retrieve this information . For A2A application, there is no clear way around the size of PQC algorithms and their impact on ADS-B Authentication. Further study is needed.
PQC size impact on ADS-B The SNOVA algorithm (under consideration by NIST for additional PQC algorithms) is an example of PQC algorithm that MAY fit within ADS-B. If EdDSA25519 is still used for the ADS-B certificate (as short-lived per-flight keys) and SNOVA is used for the Issuer certificate, only the Compact Token is impacted. Using SNOVA (37,17,16,2 {sig = 106bytes, PK=9,842bytes}), the signature in the Compact Token grows by 42 bytes (106-64). If SNOVA (25,8,16,3 {sig = 165bytes, PK=2,230bytes}) is used for EE as well, the impact is considerable. The Signed Key Disclosure grows by 101 bytes (165-64) and the Compact Token grows by 2300 bytes (2230-32+165-64). These numbers show the physical limitations of the ADS-B messaging and even the smallest considered PQC algorithm.
References DO-260C - Minimum Operational Performance Standards for 1090 MHz Extended Squitter Automatic Dependent Surveillance – Broadcast (ADS-B) and Traffic Information Services – Broadcast (TIS-B) Radio Technical Commission for Aeronautics Aviation Common Certificate Policy (Doc 10169) International Civil Aviation Organization Defined terms from the Annexes to the Chicago Convention and ICAO guidance material International Civil Aviation Organization ADS-B Performance with Small UAS at Low Altitudes Mitre EUROCONTROL Guidelines on Mode S Interrogation Configuration to Reduce 1030/1090 MHz RF Usage EUROCONTROL US Patent US6141420A, Elliptic Curve Encryption Systems Certicom CABBA: Compatible Authenticated Bandwidth-efficient Broadcast protocol for ADS-B Polytechnique Montréal Technological University Polytechnique Montréal Technological University Polytechnique Montréal Technological University Polytechnique Montréal Technological University Rhea Group Bombardier Collins Aerospace Collins Aerospace Collins Aerospace
Phase Overlay Message Types Below is a list of PO Message Types:
JTM
Just TESLA MAC Message
PR1
PPM Resiliency 1 Message
PR2
PPM Resiliency 2 Message
DET
ADS-B DET Message
UKD
TESLA Unsigned Key Disclosure Message
SKD
TESLA Signed Key Disclosure Message
SKD2
TESLA Extended Signed Key Disclosure Message
CC
Compact Signed Token Message
CC2
Extended Compact Signed Token Message
The actual MT value needs to be assigned by the SDO maintaining this field.
New PPM Type Code One new PPM Type Code is defined in this protocol:
PO-Extended
The PPM data is an extension of the PO message
FEC (Forward Error Correction) recommendations In all cases, use of FEC here is recommended, not mandatory. Use of a FEC is based on the calculated risk of message loss as covered in each section above. Consider the following:
    1. The message frame size (196 bits) and k (number of frames) into which the authentication structures are segmented are critical parameters. EVENODD and its derivative Row Diagonal Parity (RDP) are optimized for RAID6 where there are, instead of transmission frames, disks, typically k=4 for the original data. There we are concerned with the smallest number of disk failures (in an array) greater than 1, i.e. 2, because failure of 1 disk is infrequent so failure of 2 is rare and failure of more than 2 is very rare. Thus we have only a 50% overhead for RAID6 vs the 100% overhead for RAID1 (mirroring).
    2. Both of these codes are defined only for w = number of "packets" (not what we mean by that word, instead a parameter that determines codeword substructure) that are 1 less than a prime number. So for the first few primes {2, 3, 5, 7, 11, 13} we get {1, 2, 4, 6, 10, 12}, of which 1 is useless.
    3. Both of these codes are CPU efficient only if w is very close to k.
    4. RDP requires w>=k. EVENODD requires w>k.
    5. In Signed Key Disclosure k=5 and don't yet know for sure the others in a potential range from 4 to 7.
    6. So worst case w=10 (for compact token k=7 using EVENODD) yielding (w-k)=6, a very inefficient code for the CPU operations.
    7. If compact token can be reduced to k=6 and we use RDP rather than EVENODD, we could set w=6, yielding (w-k)=2 which is not great but not terrible for CPU efficiency.
    8. Total number of "disks" (for us, transmission frames) in an array is n = (k+m) where for both of these erasure codes m=2 to correct for 2 lost "disks" (transmission frames). This yields a 50% overhead which is not great but not terrible for bandwidth efficiency.
    9. It is not clear yet how to handle varying k, due to different sizes of different authentication structures, in a single consistent scheme. Zero filling parts of the codeword in encoding & decoding but not actually transmitting frames containing only zero fills presumably should work, probably at the cost of additional CPU overhead.
    10. All this is to enable recovery from the loss of a 2nd frame out of fewer than 10 frames total (worst case for compact token including the added parity frames). That's a >20% frame loss rate when it happens (lower than that on average). If losing 2 frames out of so few is not rare, then losing 3 won't be very rare, and we still have a problem. There is already a 50% FEC overhead in the Phase Overlay frame to minimize such losses. Should we back down to simple parity (e.g. XOR FEC, see ), able to recover only a single loss, but costing half as much bandwidth overhead and less than half as much CPU overhead? What are the expected frame loss statistics?
Acknowledgments TBD