Prop osal Proto col for DME and Airplane Communication
Dan Boneh and Frank Wang Department of
Computer Science, Stanford University
fdab o,frankwg@cs.stanford.edu
1 Introduction
In this report, we provide 2 di erent authentication protocols for communication between airplanes
and DME towers. The rst one, solely using signatures, is much simpler and does not require any
knowledge of the data ahead of time but requires more authentication (512) bits to be transmitted to
the airplane. The second one using message authentication codes (MACs) and signatures has more
a detailed authentication scheme and requires knowledge of data one time interval ahead of time but
requires half (256) the number of bits for the same level of security as the the rst scheme.
2 General Setup
Both schemes have the same initial setup. The following keys and certi cations must be generated
before either of the authentication schemes can be initiated:
Every aviation authority (e.g FAA) generates a public and secret key pair (P KF AA, S KF AA). For
simplicity, the schemes only consider one aviation authority, but they can easily be extended to
include many authorities.
Every plane contains all the public keys (P KF AA) for every authority, which is manually installed
on all planes. For each public key there is an associated geographic region of DMEs where the
public key can be used to certify DMEs. The plane also has a certi cation revocation list to revoke
compromised DME secret keys.
Every DME generates a public and secret key pair (P KD M E, S KF AA) and has it signed by the
appropriate authority. The DME has the following,
(P KD M E, S KF AA, C E R TF AA)
contains (id, position, P KD M E
where C E R TF AA
DME
DME
F AA
1
, and signature of the FAA on these elds). The
certi cate on the P Kis generated manually and sent to the DME. If the any S Kis stolen or
compromised, the FAA generates a signed certi cate revocation list and distributes it to all active
DMEs. If the S Kis stolen or compromised, a new public and secret key pair needs to be generated.
The public key has to be manually installed in all airplanes.
3 Signature Scheme
This scheme is simple and uses 512 bits for authentication. The general idea is that we sign all the
messages individually and provide the key for verify the signatures. Each packet contains the
following 3 parts: data, P KD M E, and an aggregated (combination of multiple signatures) signature.
The aggregated signature contains the signature of the FAA on the C E R Tand the signature of the
DME on the data. The DME signs the data using its S KD M EF AA, and the plane veri es the signature
using P KD M E. It is important to note that this scheme tolerates packet loss because each packet is
individually signed and does not require any previous or future packets for authentication. The proof
of security and speci cs of aggregated signatures are described in Boneh et al. [1].
The signatures are done using 256-bit elliptic curves [2]. Therefore, the P KD M Eand signature are
256 bits each. The authentication requires 512 bits. However, this number can be reduced by using
lower bit curves, but this also leads to a lower security.
This scheme can be written with a small amount of code ( 100 lines) assuming that we have a
library that can do elliptic curve cryptography. In terms of speed, it takes about 3 milliseconds to
generate a 256-bit elliptic curve signature and about 70 milliseconds to verify it.
4 Hash Mac Scheme
The scheme has a more detailed authentication protocol, but it only requires 288 bits. When the rst
approaches the DME, it has to wait 10 seconds (or time intervals) before we can determine if the
data is authenticated or not. The key setup is the same as the signature scheme. However,
additional calculations and setups have to be done daily and hourly. We describe the daily setup of
the DME, the DME transmission over a 24 hour period, and then the veri cation done by the plane
over this 24 hour period.
4.1 DME Hash Chain Generation
At a speci ed time at night (preferably when there is low air tra c), the DME generates a hash chain
of keys to be used during each time interval during the day. Similar one-way chains have been used
in other broadcasting protocols [3]. In this report, our chain will be 86,400 keys long, and we will
assume each time interval is 1 second. To generate this chain, we start with the nth key (Kn). This
key should be randomly generated. The 0th key is found by applying a one-way (hash) function H n
times (e.g. K0= Hn(Kn)). In our implementation, we use Secure Hash Algorithm (SHA) 256, which is a
one way, collision resistant function that outputs 256 bits. and 128 bit keys. We take the least
signi cant 128 bits before we apply the one way function. Given a key, Kj, K= Hj i(Kj) for j > i. The
keys are used in reverse order. In other words, time interval 0 uses K0i, time interval 1 uses K1, etc.
Knowing any previous key allows to see if a future key was generated from the same previous key.
A one way function means that there is no known inverse function, so it would be very di cult to nd
Kjknowing Kfor j > i. We need some way to store this chain. We can calculate it all at once and store
it, which would require O(n) space but constant time for retrieval. We can just calculate K0iand
recompute the chain every time, which would require O(n) time but constant space. Re-generating
the hash chain every time would be computationally expensive. For a chain with 86,400 keys, it
takes about 135 milliseconds. Jakobsson [4], and Coppersmith and Jakobsson [5] describe a
method for computing the next value in the chain with n elements that requires O(log n) space and
O(log n) time for each retrieval.
4.2 Transmission of the DME over a 24 hour period
Every 10 minute window contains 600 time intervals. Let Kwbe the rst key from the hash chain
associated with the current 10 minute time window.
2
At the beginning of each 10 minute time window, the DME generates S I G, which is the signing of
Kwusing S KD M ED M Eand an aggregated signature (AggSig) using the same method as above
containing S I GD M Eand the FAA signature on C E R TD M E. Therefore, we have the following
signature:
= (P KD M E, AggSig, Kw
S I GO V E R ALL64
i
i+1
= MAC[Ki+1, datai+1
[data i
i
i+1
O V E R ALL
i
i
i+1
O V E R ALL
) This is total of 640 bits because
the public key is 256 bits, the aggregated signatures is 256 bits,
and the key is 128 bits. This signature de nes a polynomial F over GF(2) of degree 9. The
importance of the polynomial is described below.
4.2.1 Transmission every time interval At time interval i, the DME sends data. It computes the
following: t|| (32-bit time)] Note that this MAC requires one time interval advance knowledge. Our
implementation uses
HMAC-SHA256. We take the least signi cant 64 bits. The 32-bit time is included in the MAC
calculation to prevent replay attacks, but dataimay only contain the 16 least signi cant time bits.
The 16 most signi cation bits are known to both the DME and the plane and need not be
transmitted because it is within the 24 hour window.
,K ,t
The DME sends the following: [data
is 128 bits, ti+1
,K
i
,t
3
, F(i)] Kis 64 bits, and F(i) is 64 bits. Therefore,
the authentication requires 256 bits. It is important to note that the polynomial changes every 600
time intervals. Any 10 packets are su cient to recover F which gives the plane S I Gand allows it to
verify the signatures. This information dispersal allows for packet loss.
4.2.2 Last 16 time intervals in 24-hour p erio d DME
sends the following:
, F’(i)] Everything represents the same as above
except F’ is the polynomial for the rst S I Gin the next 24 hour chain
4.3 Important Notes about the DME transmission
4.3.1 24 hour chain When switching between chains, the transition is smooth unless there is a burst
of packet loss, in
which the plane ill need to wait a few seconds until it receives a new complete signature.
Increasing chain length would make this event less frequent, but will increase the time to rst build
the chain and access the chain. The hash chain ensures that palnes can recover from a burst
packet loss by dropping no more than on packet. However, if an attacker is able to block every
other packet, the plane will be unable to authenticate any packet. We will show why this is the
case in the plane veri cation section below.
4.3.2 10 minut e window Signature is used for 10 minutes, but this time is variable. Increasing the
window size will make it
harder for to verify key Kiit receives in current packet because it has to perform the hash function to
get that key. Shrinking this window reduces the opportunity for recovering the signature.
4.3.3 Last 16 packets in 24 hour window Sending the signature on the new K0in last 16 packets of
current chain. Increasing the number reduces the possibility of packet loss, but makes it more di cult
for new planes coming into contact with the DME to verify the end of the previous chain because the
signature is for the new chain. New planes joining at the end of a chain will, in the worst case, need
to wait 16 seconds before they can authenticate data (as opposed to 10 seconds normally). Planes
currently using DME are una ected by change of chain, unless there is packet loss during the
change of chain.
4.4 Plane Veri cation Process
4.4.1 First Conta ct with the DME The plane collects 10 packs from the DME and reconstructs S I GO
V E R ALLas described above. After reconstructing, it veri es the signatures. At this point, the plane has
authenticated Kfor the current 10 minutes time window. This means that the plane knows the DME is
the DME it claims to be. When the next packet P , which contains [datai, Ki, ti+1w, F(i)], is received,
the plane checks that H(H(H..H(Ki)..)) = Kw, otherwise reject the packet if not. The plane can do this
because it knows what time P was transmitted and when Kwas created. After that, the plane checks
veri es that tiw(from the previous packet) is equal to MAC(Ki, [datai|| (32-bit time)]). If it is equal, then
output valid, and reject the packet otherwise. If it is valid, that means the datai
is authenticated and can be used securely.
4.4.2 Subsequent contac t The method is the same as above. If there is a gap in chain due to packet
loss, the plane waits until
the next packet is received. It ignores that packet but saves tfrom it. Then, when the next packet is
received, the plane performs the MAC check described above. It is important to mention that if an
attacker is able to block every other packet, the plane will be unable to authenticate any packet
because we could never get the keys or data from the next packet to authenticate the MAC eld from
the previous packet. If the packets happen to be the last packets in 24 hour chain, the plane collects
S I GO V E R ALLon the new K0i+1. The plane veri es the signatures and then starts using the new
chain. No interruption in the service is expected. If packet loss occurs and prevents the acquisition of
the signature on Kfrom last 16 packets of previous chain, then use signatures on the new chain to
verify K00as if the packets did not come. This method is more involved but has less bits. It can be
written in about 500 lines of code.
The signature veri cation is the same speed as above.
References
[1]D. Boneh, H. Shacham, and B. Lynn. Short signatures from the Weil pairing. J. of Cryptology
17(4): p.297-319, 2004.
4
[2]D. Freeman. Constructing Pairing-Friendly Elliptic Curves with Embedding Degree 10. Algorithmic
Number Theory : p. 452-65, 2006.
[3]A. Perrig, R. Canetti, J.D. Tygar, and D. Song. The TESLA Broadcast Authentication Protocol.
RSA Cryptobytes 5: p.2002, 2002.
[4]M. Jakobsson. Fractal hash sequence representation and traversal. In Proceedings of the 2002
IEEE International Symposium on Information Theory, p. 437-44, July 2002.
[5]D. Coppersmith and M. Jakobsson. Almost optimal hash sequence traversal. In Proceedings of
the Fourth Conference on Financial Cryptography, 2002.
5