Proposal Protocol for DME and Airplane Communication

Proposal Protocol for DME and Airplane Communication
1 Introduction
Dan Boneh and Frank Wang
Department of Computer Science, Stanford University
{dabo,frankw}@cs.stanford.edu
In this report, we provide 2 different authentication protocols for communication between airplanes
and DME towers. The first 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 first scheme.
2 General Setup
Both schemes have the same initial setup. The following keys and certifications 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, SKF 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 certification revocation
list to revoke compromised DME secret keys.
• Every DME generates a public and secret key pair (P KDME, SKF AA) and has it signed by
the appropriate authority. The DME has the following,
(P KDME, SKF AA, CERTF AA)
where CERTF AA contains (id, position, P KDME, and signature of the FAA on these fields).
The certificate on the P KDME is generated manually and sent to the DME.
If the any SKDME is stolen or compromised, the FAA generates a signed certificate revocation
list and distributes it to all active DMEs. If the SKF AA is 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
1

following 3 parts: data, P KDME, and an aggregated (combination of multiple signatures) signature.
The aggregated signature contains the signature of the FAA on the CERTF AA and the signature
of the DME on the data. The DME signs the data using its SKDME, and the plane verifies the
signature using P KDME. 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 specifics of aggregated signatures are described in Boneh et al. [1].
The signatures are done using 256-bit elliptic curves [2]. Therefore, the P KDME and 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
first 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 verification done by the
plane over this 24 hour period.
4.1 DME Hash Chain Generation
At a specified time at night (preferably when there is low air traffic), 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 = H n (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 significant 128 bits before we apply the one way function. Given a key, Kj, Ki =
H j−i (Kj) for j > i.
The keys are used in reverse order. In other words, time interval 0 uses K0, 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 difficult to find Kj knowing Ki for 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 K0 and 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 Kw be the first 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 SIGDME, which is the
signing of Kw using SKDME and an aggregated signature (AggSig) using the same method as above
containing SIGDME and the FAA signature on CERTDME. Therefore, we have the following
signature:
SIGOV ERALL = (P KDME, AggSig, Kw)
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 defines a polynomial F over GF(2 64 ) 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 datai. It computes the following:
ti+1 = MAC[Ki+1, datai+1 —— (32-bit time)]
Note that this MAC requires one time interval advance knowledge. Our implementation uses
HMAC-SHA256. We take the least significant 64 bits. The 32-bit time is included in the MAC
calculation to prevent replay attacks, but datai may only contain the 16 least significant time
bits. The 16 most signification bits are known to both the DME and the plane and need not be
transmitted because it is within the 24 hour window.
The DME sends the following:
[datai, Ki, ti+1, F(i)]
Ki is 128 bits, ti+1 is 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
sufficient to recover F which gives the plane SIGOV ERALL and allows it to verify the signatures.
This information dispersal allows for packet loss.
4.2.2 Last 16 time intervals in 24-hour period
DME sends the following:
[datai, Ki, ti+1, F’(i)]
Everything represents the same as above except F’ is the polynomial for the first SIGOV ERALL in
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 first 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
verification section below.
3

4.3.2 10 minute window
Signature is used for 10 minutes, but this time is variable. Increasing the window size will make it
harder for to verify key Ki it 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 K0 in last 16 packets of current chain. Increasing the number
reduces the possibility of packet loss, but makes it more difficult 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
unaffected by change of chain, unless there is packet loss during the change of chain.
4.4 Plane Verification Process
4.4.1 First Contact with the DME
The plane collects 10 packs from the DME and reconstructs SIGOV ERALL as described above.
After reconstructing, it verifies the signatures. At this point, the plane has authenticated Kw for
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+1, 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 Kw was created. After that, the plane
checks verifies that ti (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 contact
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 ti+1 from 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
field from the previous packet. If the packets happen to be the last packets in 24 hour chain, the
plane collects SIGOV ERALL on the new K0. The plane verifies 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 K0 from last 16 packets of previous chain, then use signatures on
the new chain to verify K0 as 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 verification 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