a navigation message authentication proposal for the...

A Navigation Message Authentication Proposalfor the Galileo Open Service

IGNACIO FERNÁNDEZ-HERNÁNDEZEuropean Commission, Belgium

VINCENT RIJMENUniversity of Leuven (KU Leuven), Belgium

GONZALO SECO-GRANADOSUniversitat Autònoma de Barcelona, Spain

JAVIER SIMONEuropean GNSS Agency, Czech Republic

IRMA RODRÍGUEZ and J. DAVID CALLEGMV, Spain

ABSTRACT: GNSS vulnerabilities have become evident in the last decade. Authentication of the GNSS signals anddata can be an important building block contributing to mitigating these vulnerabilities. This paper presents aNavigation Message Authentication (NMA) scheme based on the Timed Efficient Stream Loss-tolerantAuthentication (TESLA) protocol and a novel concept based on a single one-way chain for all senders and cross-authentication. The paper presents an NMA implementation in the Galileo Open Service (OS) navigation messagethat should provide similar navigation performance to data-authenticated users and standard non-authenticatedusers in terms of time to first fix, accuracy, and availability even in difficult reception conditions. The proposal alsomaintains a high level of signal unpredictability to help receivers protect against replay attacks. The scheme andimplementation proposed yield significant improvements compared to the state of the art, offering the opportunityfor Galileo to become the reference GNSS in civil navigation authentication. Copyright # 2016 Institute ofNavigation

MOTIVATION AND CONTEXT

The need to mitigate GNSS vulnerabilities hasbecome evident in recent decades [1], as highlightedby articles in this Journal over the past years [2, 3].In particular, a recent survey of spoofingcountermeasures [3] proposed the addition ofcryptographic protection of the navigation messageamong other solutions such as inertial sensors,stable clocks, or antenna arrays. NavigationMessage Authentication, or NMA, generally refersto the authentication of the navigation databroadcast by a GNSS [4]. Civil users receiving opensignals can authenticate GNSS data through adigital signature [2], if their receivers have anauthentic public key to validate the signature.Authentication can also follow hybrid (symmetric/asymmetric) approaches relying on time-delayedasymmetry, e.g., through the TESLA (TimedEfficient Stream Loss-tolerant Authentication)

protocol [5], as proposed in this article. In additionto data authentication, previous literature proposesand characterizes detection methods of replayattacks based on the unpredictable bits or symbolsof NMA [3, 6].The Galileo signal design and message structure is

suitable for introducing authentication, as it allowshigher bitrates compared to other GNSS [7, 8] and,due to the Galileo safety-of-life service re-profiling asignificant amount of bandwidth has been liberatedfor other uses.The main problem targeted in this article is how to

provide an NMA service that maximizes availabilityand robustness within the Galileo I/NAV E1-B OpenService signal, in a fully backward-compatible waywith the current Signal In Space Interface ControlDocument (SIS ICD) [8], and with minimum changesto the deployed infrastructure.In 2014, a proof-of-concept platform developed

and tested a Galileo NMA solution with the realSIS, verifying its feasibility [9]. At the time ofwriting this article, new Galileo requirements toinclude NMA are being studied for incorporation

NAVIGATION: Journal of The Institute of NavigationVol. 63, No. 1, Spring 2016Printed in the U.S.A.

85

in the Galileo technical baseline, which shouldallow provision of NMA before the end of thisdecade. While the work presented in this articlehas influenced this process, the final GalileoNMA implementation may still be subject tomodifications in the years to come.

PERFORMANCE MEASURES

As a general principle, an optimally designed NMAsolution should not degrade navigation accuracy oravailability and should minimize the differencebetween Time To First Authenticated Fix (TTFAF,i.e., the time to calculate a first position based ondata-authenticated satellites) and standard, non-authenticated Time To First Fix (TTFF). The impactof NMA on standard navigation performanceindicators such as availability or accuracy ispresented in [10] and [11]. There it is explained thatthe navigation performance and robustness againstattacks are strongly dependent on AuthenticationError Rate (AER) and Time Between Authentications(TBA). AER represents the probability of error ofauthenticating a satellite in the absence of attacks,but in the presence of disturbances in thetransmission channel. It is therefore equivalent topacket error rate, where the packet comprises thenavigation and authentication information requiredto perform the authentication verification.

AER ¼ 1� 1� BERð ÞNNA (1)

where BER is the bit error rate and NNA is thenumber of bits used in the authentication, whichincludes the plaintext navigation bits to beauthenticated (NN), and the authentication bits(NA). TBA represents the time between twosuccessive satellite authentications. When satellitesare authenticated at different times (as proposed in[2] and later in this article), a distinction should bemade between all-in-view TBA, i.e., the time betweenauthentications of any satellite in view by a receiver,and single-channel TBA, i.e., the time betweenauthentications of a given satellite. Unless specificallystated, this paper refers by default to the latter.TBA influences the TTFAF and bounds the time

during which a user can be spoofed without it beingreported by the authentication system. For example,a TBA of 10 seconds implies that any attackaltering the unpredictable cryptographic informationtransmitted by a satellite can be detected with amaximum delay of 10s.Together with AER and TBA, MaximumPredictable

Time (MPT) and Unpredictable Symbol Ratio (USR)can characterize the level of protection against signalreplay attacks. MPT represents the maximum timethat the signal will be predictable. USR, in thecontext of this work, reflects the percentage ofunpredictable symbols out of the total number of

symbols over a given time period. USR gives anindicator of how long a receiver has to wait beforehaving a reliable test statistic to protect againstreplay attacks.

Based on these performancemeasures, the problemtreated in this work can be restated as how to designan NMA scheme that does not degrade performanceand minimizes AER and TBA, while maximizing theprobability of detecting a replayed signal by a receiverimplementing the appropriate anti-replay checks.

PROPOSED AUTHENTICATION CONCEPT

This section presents the authentication concepton which the proposed implementation is based. Itrelies on two main principles:

• The authentication of data from some satellitesby other satellites, or cross-authentication, asdescribed in [10].

• The use of different keys from differentsatellites but from a single one-way chain sharedby all satellites, through a Timed EfficientStream Loss-tolerant Authentication (TESLA)protocol [5].

The TESLA Protocol Features

The main properties of the TESLA protocol makeit very suitable for radionavigation authentication.These properties are [5] are as follows:

• Low computation overhead for the generation,and mainly the validation, of authenticationinformation.

• Low communication overhead. This is a criticalproperty for AER and TBA.

• Strong robustness to data loss, as is the case forGNSS receivers in environments with reducedvisibility.

• Optimal formulticast (one-to-many) transmissions,as is the case for GNSS.

TESLA is based on the transmission of a MessageAuthentication Code (MAC) to authenticate theplaintext message and the delayed transmission ofthe key used to compute the MAC. This key belongsto a chain generated through a one-way function F.The chain starts with a random seed key Kn, whichis secret, and ends with a root key K0 that is publicand certified as authentic:

K0 ¼ Fn Knð Þ (2)

where Fn means recursively applying n times thefunction F. A hash function (e.g., SHA-256 [12]) is aone-way function, so each element of the chain canbe constructed by hashing the previous element. Theidea of defining password chains, on which the TESLAprotocol is based, was first described in [13]. In

86 Navigation Spring 2016

addition to the obvious requirement that thecryptographic functions usedmust be cryptographicallysecure, two assumptions are required for TESLA toprovide security: First, the receiver must be looselysynchronized with the transmitter. Second, anotherauthentication system is required at start-up: Thereceiver is required to have an authentic root key.

The cryptographic strength of the chain generationmechanism is greatly increased by breaking thesymmetry of the iterations. This can be done byadding additional information to the hashing processthat is known to the receiver, e.g., a counter or a timetag. In addition, the key size can be reduced bytruncating the hash output, in order to reducecommunication overhead. In this article, the functionF is proposed as follows:

F Km; GSTj

� � ¼ trunc len; hash Km jj GSTj

� �� (3)

where Km is the key used as an input to the function,GSTj is the Galileo System Time associated with thebeginning of the authentication frame j in which thekey will be applied, trunc is the truncation functionto the lenmost significant bit (MSB), len is the lengthof the key, hash is the hash function used, and || isthe operator to concatenate Km and GSTj into asingle bit chain. An authentication frame here refersto the interval of time during which newauthentication information (MACs and key) istransmitted. At the end of an authentication frame,the receiver can perform a new authentication check.

Adding GSTj to the hashing process protectsagainst pre-computation attacks. In such attacks,an attacker would pre-compute and store long hashchains, and when one of the broadcast chainelements appears in the precomputed chains, theattacker would have knowledge of the followingkeys. GSTj is different for each iteration of thehashing process. By adding it to the key computationprocess, pre-computation attacks, which otherwisewould seem to have the highest probability ofsuccess, are neutralized, since attackers are forcedto specify in advance for which time slot they areperforming the pre-computations. Other options toprotect against pre-computation attacks areincreasing the key size, with the consequentincrease in communication overhead, or associatingan unpredictable pattern with each chain andtransmitting it just before the beginning of the chainentry into operation. Both options are described inmore detail in [14].

GNSS authentication through TESLA would beperformed in the following way:

• The receiver receives the navigation data andthe MAC.

• The receiver later receives a key from which theMAC can be generated.

• The receiver authenticates the key with aprevious key from the chain that is consideredauthentic, or the root key, by performing functionF the required number of times.

• The receiver re-generates the MAC with the keyand the data, which should coincide with thepreviously received MAC.

More details about TESLA protocol implementationsfor GNSS can be found in [4, 11, 15–17]. Now that theTESLA protocol and its use for GNSS have beengenerally described, the next sections will deal withthe specificities of the proposed scheme.

TESLA with a Single Chain from Several Senders

In a standard TESLA approach, as presented inthe consulted literature, each sender (satellite) usesa different one-way chain. If a receiver authenticatesfour satellites, it should receive, in addition to thedata, four MACs and four keys, one from eachsatellite, where each key belongs to a different chainand needs a different root key to be validated. On thecontrary, the proposed scheme uses a single one-waychain for all senders [18]. The main motivation forthis choice is to drastically reduce AER: by allowingall satellites to be authenticated through the samechain, a user needs to receive only one key fromany satellite, and four MACs, to authenticate allsatellites. Combined with the high MAC truncationexplained later, this dramatically reduces thenumber of bits required for calculating a PVT usingdata-authenticated satellites. In addition, a singlechain will also help in the initialization, as only oneroot key is required for all satellites, reducing thetime to first authenticated fix (TTFAF). The use of asingle chain is especially useful when one or a fewsatellite signals are received in good condition whileothers are received at lower elevation angles orsubjected to multipath or blockage and thereforedemodulated with a much higher bit error rate,which may be the case in urban environments. Notethat even if, due to shadowing or fading, no key issuccessfully demodulated from any satellite for acertain authentication frame, any key from the nextauthentication frame can be used to verify theprevious ones.

TESLA with a Single Chain and Different Keys fromDifferent Senders

One problem that arises when using a single one-way chain is that if the same key is used by allsatellites, even if it is transmitted at the samereference time, it will be received at different timesby users due to satellite clock offsets and, principally,different times of arrival. As a result, only the keyarriving from one satellite is unpredictable, which

87Fernandez-Hernandez et al.: NMA proposal for Galileo OSVol. 63, No. 1

makes the signals from other satellites easier toreplay. This problem can be overcome by transmittingdifferent keys from different satellites, but still fromthe same chain. In this way, the keys would still beunpredictable while the MAC key is recoverable fromany later key of the chain. Following this scheme, in agiven authentication frame j, the key used for theMACs (Kj,MAC) can be derived from the key receivedfrom satellite i as follows:

Kj;MAC ¼ Fi�1 Kj;i; GSTj

� �(4)

where Fi� 1 is the F function in Equation (3) appliedi�1 times to Kj,i, the key received from satellite i inauthentication frame j. In this case, the key Kj,1

would be transmitted by satellite 1 at authenticationframe j and also used for the MAC computation, i.e.,Kj,1 = Kj,MAC. To avoid the reuse of the key, anotherchain element can be added, or an additionalfunction can be used to generate the MAC keys fromthe transmitted keys as proposed in [5] and [15]. Forthe sake of simplicity, this is not part of the describedsolution, although it may be added to futureschemes. In any case, the conclusions derived in thispaper are not affected by this potential addition.To validate the MAC key in authentication frame j

with the MAC key from the previous frame j�1:

Kj�1;MAC ¼ FS Kj;MAC ; GSTj�1� �

(5)

where S is a constant representing the maximumnumber of satellites, i.e., the maximum number oftimes the function F is executed in oneauthentication frame. The main drawback of thisapproach compared to the use of one key perauthentication frame is that it requires highercomputational power, as the number of one-wayoperations per chain will be higher. For example, ifS=40, the chain would become 40 times longer.Assessment of the additional CPU needs for thisapproach is covered in a later section.Figure 1 and Figure 2 show how the keys of a

certain chain are transmitted and used every timethe receiver performs an authentication. Thediscontinuous lines of Figure 2 for the keys implythat, as explained above, the receiver (Rx) only needsto receive a key from any satellite to authenticate allMACs. As an example, if TBA is 10seconds, every

10seconds each satellite would send at least oneMACauthenticating the satellite datawith a key that,for the 10-second period of authentication frame j, isKj,1. This key would also be transmitted from SVID(Space Vehicle ID) 1, while SVID 2 would transmitthe previous key in the chain Kj,2, SVID 3 wouldtransmit Kj,3, and so on. In this way, a spoofer wouldbe unable to predict the key of one satellite from thatof another. One could argue that if SVID 2 is closerthan SVID 1 to the receiver, an attacker could predictKj,1 from Kj,2. However, as the transmission of thekeys is done in parallel, only the very few final bits ofKj,1 could be predicted by having a high number of bitsof Kj,2, rendering such an attack rather impractical.User implementations must discard the last bits ofthe key in the anti-replay statistics.

TESLA and Cross-Authentication

In order to be available in this decade and with anaffordable impact on the system infrastructure, theGalileo NMA must be generated on-ground andtransmitted in real time to the satellites for broadcast.This ground-to-satellite continuous connection is alsoused by other satellite systems, such as SBAS, andother geostationary satellite-based services. Itwas predicted for the Galileo safety-of-life service,it is partly required for the regular Galileonavigation data update, and it is also requiredfor the provision of high accuracy (PPP) throughthe future Galileo Commercial Service [9].However, generating NMA on-ground means thatonly satellites connected to ground can deliverNMA in the Galileo first generation. This meansno more than 20 out of 24 Galileo satellites. Toovercome this limitation, the navigation data ofthe satellites not connected to ground at a giventime can be authenticated by those connected toground and transmitting authentication data: SeveralMACs can be associated with each key, allowing cross-authentication of some satellites by others. Thisfeature opens the door to cross-authenticating datafrom other GNSS constellations.

Figure 3 shows how satellites 2 and 4 canauthenticate their own navigation message (N2, N4)and cross-authenticate the surrounding (non-connected)

Fig. 1–TESLA one-way chain with different keys from different senders. [Color figure can beviewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]


satellites 1, 3 and 5. This scheme may lead toduplications in the transmitted information (e.g.,MAC(N3,Kj) in the figure) or to the reception ofauthentication for satellites that are out of view.However, it ensures the authentication of all thenavigation information received by all users onEarth. Note, however, that if N1, N3, and N5are predictable, which is generally the case,satellites 1, 3, and 5 would not be protectedagainst replay attacks.

Taking into account the cross-authenticationfeature, generation of the MACs is performed asfollows:

MACj;i;l ¼ trunc n; mac Kj;MAC ; i jj lð j� �� CTR� ��j Pj;lÞÞÞ

(6)

where MACj,i,l is the tag (or truncated MAC)transmitted at frame j by satellite i to authenticate

the navigation of satellite l (note that i and l coincidewhen the satellite self-authenticates, as shown inFigure 2), CTR is a counter with the position of thetag in the transmission, and Pj,l is the navigationdata of satellite l at frame j that is authenticated.Note that, by using the cross-authenticationapproach, a satellite can transmit several MACs,for itself and the neighboring satellites. Examplesof typical MAC functions used are HMAC-SHA-256,as standardized in [19], and CMAC-AES,standardized as Algorithm 5 in [20]. Note that thesignal time is authenticated by ensuring the keyauthenticity with respect to the K-root: If a key of acertain subframe is authenticated using the TOW(Time Of Week) of that subframe, the TOW must beauthentic too as otherwise the one-way processbased on Equation (2) would not lead to the validK-root. Notice also that, if l were not authenticated,

Fig. 2–TESLA single-chain approach with a different key transmitted by each sender.No cross-authentication. [Color figure can be viewed in the online issue, which isavailable at wileyonlinelibrary.com and www.ion.org]

Fig. 3–TESLA single-chain approach with connected (2,4) and non-connected (1, 3, 5)satellites. [Color figure can be viewed in the online issue, which is available atwileyonlinelibrary.com and www.ion.org]


given that all MACs in a MAC-K section are signedwith the same key, an attacker could forge the signaland transmit the same navigation data from severalsatellites and later replay the first MAC.

IMPLEMENTATION TRADE-OFFS AND ANALYSES

This section presents some tradeoffs intendedto justify the design decisions leading to theimplementation presented throughout the rest ofthe article.

Digital Signatures versus Time-DelayedAsymmetry

To maximize the use of GNSS authentication,cryptographic key management should be simplifiedas much as possible. This means that asymmetricschemes, where the user receivers only need topossess a public key, are preferred to symmetricschemes, where the user needs to store a secret keyin a security module within the receiver. Asymmetricschemes can be achieved mainly through two options:

• Digital signatures, such as RSA, DSA, orECDSA [21]. In these schemes, the satellitestransmit a digital signature of their navigationdata, as described in [2].

• Delayed symmetric key delivery, such asTESLA.

The main advantage of authentication throughdigital signatures is that there are known methodsand functions in the cryptographic standards thatmake them reliable for the cryptographic community[21]. The main disadvantage of authenticationthrough digital signatures, compared to time-delayed asymmetric approaches, is the bandwidthrequired to transmit the authentication information.For example, in order to transmit a digital signaturethat guarantees a 112-bit to 128-bit security level,signatures on the order of 500bits are required(e.g., 512bits for standard DSA, 128-bit security, or466bits for 112-bit security through the Elliptic CurveDigital Signature Algorithm (ECDSA), as per [2]).Another disadvantage is the computational effortrequired for each authentication. The main advantageof time-delayed asymmetric schemes is the bandwidthreduction and the tolerance to data loss, as mentionedabove. Their main disadvantages may be that they arenot as standardized and accepted by the cryptographiccommunity as digital signatures and they arepotentially vulnerable to more threats, as they relyon a coarse time synchronization of the receiver witha time reference. In any case, to authenticate theSIS, the receiver must possess some informationcertified as correct independently from the SIS.This means that even for TESLA-based approaches,

the receiver must possess a public key toauthenticate the SIS. However, the frequency withwhich this public key is used, and the bandwidthassociated with this process, can be very low, as inthe proposed implementation.

Preliminary Assessment of the CPU Needs of aSingle One-Way Chain

To understand the computational power requiredin a single one-way chain where each satellitetransmits a different key, state-of-the-art SHA-2implementations have been studied. It is claimedthat around 11.5 processor cycles per byte arerequired [22]. As a rough estimation, a 1-GHzprocessor would need around 0.4microseconds for aSHA-256 (i.e., 32 bytes) iteration. For the followingassessment, and taking into account that the one-way function may also involve the concatenation of atime tag, and a truncation, 1microsecond periteration is considered. The CPU time required for asingle-chainmultiple-key TESLAapproach, assuming40 iterations per authentication (allowing coverage of30+ satellites), would therefore be 40microsecondsfor the whole set of satellites every authenticationframe, as the operation is required only once for allsatellites, which in absolute terms is very affordablefor a standard low-end processor. Regarding theCPU needed to verify a certain key against anauthenticated root key, which is, for example, 1weekolder, and assuming 40 hash iterations for a 10-secondauthentication frame, 2,419,200 iterations would berequired, i.e., around 2.5 seconds, which is highlyaffordable taking into account that this operation isvery infrequent. Therefore, the CPU computing powerrequired seems not to be a major driver. Note that, ina standard 1-chain-per-sender TESLA approach, thechain verification is required for each satellite,leading to lower but still comparable computingpower needs.

Security Considerations of a Single One-Way Chain

By using only one chain for all satellites, if thechain is compromised (i.e., the seed key Kn is found),the whole system is compromised. However, as theone-way chain security depends on the choice of thehash primitive and hash bit output length, acryptographically secure design choice for severalchains is as secure for a one-way all-satellite chain.Instead of protecting several seed keys per chain,the system protects only one, but the existence ofsingle versus multiple parallel chains does notchange the system architecture, as the securitymeasures of the system are similar.

To increase security, the hash function and the keylength can be chosen with high margins. If, due tothe higher criticality of compromising a single Kn,


higher security measures are required, the validityperiod of each chain could be shortened, or the keybit length increased, or other system-relatedmeasures could be introduced, while maintainingthe advantages of the current concept. As shownlater, the proposed implementation permits changesto the key and MAC lengths as well as thecryptographic functions in order to cope with futurethreats over the lifetime of the service.

Security Considerations on MAC Truncation andOne-Way Function Truncation

For applications with large bandwidths comparedto the output sizes of cryptographic algorithms, it iscommon to use MAC functions with output sizes of80 or even 160bits, as is the case for some HMACfunctions [23]. However, meaningful levels ofsecurity are achieved with much shorter outputsizes. Given the low throughput available in GNSSsignals, the lengths of the key and the truncatedMACsare very sensitive parameters. They influence thenumber of authentication bits (NA) and thereforeaffect AER and TBA (the latter assuming a fixedbandwidth), which are reflected in all other indicators.Therefore, their length should be reduced as much aspossible while maintaining security at an acceptablelevel. As GNSS are one-way systems, an attacker hasno control over the message that is authenticated(i.e., it cannot request a satellite to authenticate a givenmessage) or the key used, and the MAC and keytransmission occurs with a certain cadence controlledby the system specification. This yields some attacksimpractical, permitting the use of very short MACs.

Assuming the MAC algorithm behaves as a lookuptable with a message and a key as entries, and ann-bit random sequence as output, an attacker couldonly try to guess the MAC, which is very unlikelyeven for extremely truncated MACs to only a veryfew bits [10, 17]. For example, a MAC as short as10bits would be guessed with an average probabilityof 0.097% (one time out of 1024), rendering the ‘MACguessing’ \ compared to a pure service denial by,e.g., jamming the signal. Some additionalprotections against this attack are as follows:

• A receiver can accumulate two or more MACsbefore accepting the data as authenticated. Giventhe very short TBAs and the possibility to cross-authenticate several satellites, this permits dataauthentication with higher probabilities with adelay of a few seconds, or even without any delay.For example, one can imagine a receiver that onlyuses a new Issue Of Data (IOD) when it isauthenticated twice, reducing the ‘MAC guessing’probability to 1/(1024)2 and navigating in themeantime with the previous IOD, which shouldminimally affect the navigation performance.

• Each MAC-Info section could be encrypted withthe key delivered later, making the ‘MACguessing’ attack more difficult and also addingunpredictability to the signals.

Security Considerations on Key Length

Regarding the symmetric key length used in the one-way chain, in accordancewith [24] and [25], we considera key length of 80bits to be strong enough for chaindurations of up to 1year (at the time of writing). Theinclusion of information that changes with everyiteration to the input of the hash function, cf. Equation(3), works as a ‘salt’ and counters multiple-targetattacks on the hash function, thereby significantlyincreasing the strength of the mechanism. If the keyhas to be guaranteed for, e.g., 20 or 30 years, 128-bitkeys would be recommended [26]. While [26] proposesto restrict the use of 80-bit keys to legacy applications,we point out that [27] allows the continued use of80-bit keys when each key encrypts less than 220 blocksof plaintext, which is the case here. Furthermore, theuse of 80-bit keys is in accordance with the stillwidespread use of 160-bit hash functions like SHA-1and RIPEMD-160, and the current implementationallows longer keys in future chains (up to 128bits).To accommodate keys as short as 80bits in a

standard one-way function such as SHA-256 [12]or SHA-3 [28], the one-way function needs totruncate the output of the hash function to thelength of the key for every iteration in the chain,as shown in Equation (3).

Root Key Authentication and Public KeyManagement

In addition to the SIS information, the systemshall provide a public key through other means thanthe SIS, allowing the verification of the root key by adigital signature. The authenticity of the public keymust be ensured, e.g., by allowing access to thereceivers to a trusted public source containing thepublic key(s) or the fingerprints of the public keys.An external certification authority may also be used.A public-private key pair may be valid for several

years, but possibly not for long enough to cover theentire lifetime of the system. Moreover, public–privatekeys may need to be revoked. Also, the public keyscannot be published much before their validity period,as otherwise the paired private key could be attackedby the knowledge of the public key, even if noinformation has been yet signed to it. Therefore, thesystem must be able to provide new public keys to theusers. To provide a newpublic key, different approachesmay be followed. Either the system does over-the-airrekeying for the public key [17] or the receiver connectsto a network to obtain it. Otherwise, publishing keyswith a certain frequency and validity period of, e.g.,1year and 5 years, respectively, and sending digital


signatures using all of the keys would allow receiversnot to have to download the keys for some years. Allapproaches have pros and cons regarding autonomyand management of key revocation, but they provethat public-private key management schemes granta high autonomy to NMA receivers.

IMPLEMENTATION EXAMPLE: NMA IN GALILEOE1-B I/NAV

This section presents an implementation of theproposed NMA concept in the Galileo I/NAVmessagestructure, which is based on the transmission of afull navigation frame every 750 seconds. The I/NAVframe is composed of 30-second subframes, whichalways transmit all the required positioningparameters except the almanac. Every subframe isdivided into 15 2-second pages, each of whichcontains one word and some other fields, as shownin Figure 4. A total of 125bps can be transmitted inthe E1-B I/NAV message. These bits areconvolutionally encoded at 250 sps and interleaved.The E1-B symbol stream is modulated through aDirect Sequence Spread Spectrum (DSSS)technique with 4092-chip pseudorandom codes at1.023Mcps, and with a subcarrier at 1.023MHz toachieve a BOC(1,1) modulation. Thus, every 4-mssymbol is modulated within a single 4-ms code.Details about the Galileo I/NAV signals andmessage are in the Galileo OS SIS ICD [8].

We propose to use the field ‘Reserved 1’ in the ICD[8] to transmit NMA information. This field providesa bandwidth of 40 bits every other second. The reasonto use this field, as opposed to other spare fields in theI/NAV message, is that it can be filled in andtransmitted to the satellites with minimal impact onthe core mission navigation and control tasks, asexplained before and presented in more detail in[18]. Using this field also scatters the NMA bits acrossthe navigation message, reducing MPT.

Figure 4 presents the Galileo E1-B I/NAV messagestructure and highlights the position of the‘Reserved 1’ field. Note that only the same amountof symbols as unpredictable bits before encodingare considered unpredictable (i.e., a maximum of40 symbols in the current case [29]). This must betaken into consideration when assessing the MPTand USR parameters.

The 40bits-per-2-second bandwidth yields 20bps fora total of 600bits every I/NAV subframe, after which, innominal conditions, the I/NAV words are repeated.This 30-second subframe structure has also been takenas a reference for NMA, to facilitate synchronizationbetween the reference time, the authenticatednavigation data, and the authentication data.

While a thorough description of each header andfield that compose the NMA transmission structureis outside of the scope of this paper, the main datablocks of the proposed implementation are presentedin Figure 5 and explained later.

The top row of Figure 5 shows the subframetime, which goes from 0 to 30 seconds. The secondrow shows the page order, from 1 to 15. For everypage, 40bits are available for NMA. The SISauthentication information is based on two mainsections transmitted in parallel:

Fig. 4–Galileo E1B I/NAV message structure. [Color figure can beviewed in the online issue, which is available atwileyonlinelibrary.com and www.ion.org]


• ‘H-K-root’ section, with the global header and adigitally signed root key.

• ‘MAC-K’ sections, with the MACs and associateddelayed key. Three 10-second MAC-K sectionsare shown.

The authentication service will mainly be based ontheMAC-K section, which occupies 32 out of the 40bitsper word, leaving 8bits per word for the H-K-rootsection. This implies a total of 120bits per subframefor the H-K-root section and 480bits per subframe forthe MAC-K sections. The MAC-K authenticationimplements a TESLA authentication scheme, asdescribed above. To authenticate the keys used in theMAC-K section, a root key (K-root) will be continuouslydigitally signed and sent in parallel in the H-K-rootsection. Reading the root key is required only whenthe user needs a new root key, which should happenvery infrequently. Separating H-K-root and MAC-Ksections maintains a constant level of unpredictabilityand allows more flexibility in the solution design.

H-K-root Section

H-K-root will be transmitted synchronously withthe I/NAV subframe. This means that in each30-second subframe, a full H-K-root block of 120bitscan be transmitted, as depicted in Figure 5. TheH-K-root section is composed of a global Header andthe K-root digital signature and message (DSM)information. The DSM contains the root key (K-root),plus some descriptive fields that include theassociated time and the digital signature information.

The type of digital signatures used is still underconsideration and is not the main scope of this paper.Schemes such as Elliptic-Curve Nyberg-Rueppel, formessage recovery, or Schnorr-DSA, as described in[30] and [31], respectively, are plausible options. Toadd flexibility to the design, a DSM will authenticatenot only the K-root and its reference time but alsoother specific parameters of the chain, such as thekey size (which can be increased if needed), theMAC size, the one-way function (e.g., SHA-256 orSHA-3), and the MAC function (e.g., HMAC-SHA-256)

etc. In this way, the NMA solution gains in flexibilitywhile maintaining its format and specification, whichis a highly desirable parameter for a service that maybe in operation for several decades.

MAC-K Section

The section transmitted in parallel to the H-K-rootcontains the truncated MACs and keys used forauthentication. With a key length of 80–128bits anda truncated MAC length of 10–20bits, two or threekeys can be sent every subframe, one every 15 or10 seconds, respectively, with their associated MACs.The MAC-K section is composed of the following:

• A MAC section, which in turn is composed ofthe MAC and a MAC-Info section, givinginformation about the MAC.

• The key, which will follow the one-chainmultiple-key scheme mentioned above.

Figure 6 presents the structure of the MAC-Ksections. The different fields are grouped by type:all MAC and MAC-Info sections of a given MAC-K section are put in a column, the associated keyis put in the next column, and so on. The orderin which the information is received by a receiveris given by reading each row from left to right,and then from top to bottom.MACs are generated according to Equation (6).

The MAC-Info section is transmitted contiguouslywith the MAC and is composed of the following:

• A Satellite Vehicle ID field (SVID), to allow forcross-authentication of surrounding satellites,either from the same constellation or fromothers. An 8-bit field as per Figure 6 allows forup to 255 satellite IDs.

• An ‘Authentication Data & Key Delay’ field(ADKD), which can fit into 4bits and is definedas shown in Figure 7.

• A truncated issue of data field (IOD), whichidentifies the data to be signed. It may relate toan IOD from the navigation message or anotherconvention may be used, depending on theADKD case.

Fig. 5–Galileo NMA proposal within the I/NAV message structure. [Color figure can be viewedin the online issue, which is available at wileyonlinelibrary.com and www.ion.org]


While more ADKD values can be further refined,this definition is representative of the fact that eachtransmitted MAC could sign different types ofinformation not only from different satellites butalso from different signals from the same satellite,and for different sets of information. For example,in order to reduce AER by authenticating fewer bits,most of the transmitted MACs can sign only theephemeris and clock data (ADKD=0), and only afew MACs can sign the ionospheric information(ADKD=1). The meaning of the most relevantvalues of the ADKD field to understand andcharacterize the concept is described here:

• ‘0’, Eph & Clk: the MAC authenticates theephemeris and clock data bits transmitted inthe E1 I/NAV message, Words 1 to 4 as per [8].

• ‘1’, Iono+: theMAC authenticates data bits in theI/NAV Word 5: ionospheric correction, BGDs, etc.

• ‘2’, Subframe: the MAC authenticates the bits ofa full subframe, including all data words. It doesnot include other reserved fields, the SAR dataor the CRC.

• ‘11’ to ‘15’, ‘slow-MACs’: To relax theTESLA loosetime synchronization requirement in the receiver,the concept of ‘slowMACs’ is added. A ‘slowMAC’is a MAC generated with a key that will bebroadcast some subframes later. For example, ifthe ADKD field value is 15, it means that thereceiver will get the key associated to that MAC

exactly with a five-subframe delay with respectto the time it would have received it innormal conditions. If a receiver is switchedon and its clock error can be up to severalseconds before GNSS signal acquisition andsynchronization, an attacker could spoof thedata. The spoofing attack would consist ofreceiving and rebroadcasting a valid key witha navigation message including a systemtime reference coherently delayed with therebroadcast key, wrong navigation, and correctMACs computed with the already known key.Following the example, a receiver with a 5-ppmclock stability could accumulate a 10-second errorafter 23days without GNSS, which is a plausiblescenario. Transmitting ‘slow MACs’ allowsdetection of such attacks: with a five-subframedelay, the same clock would take around 370daysto accumulate such an offset.

One advantage of associating an IOD with a setof authentication data is that it ensures thatauthentication latency has very little impact onNMA performance. This is a relevant insight for thedesign of an NMA system, understanding latency asthe time between navigation data being received onground and the time the authentication is receivedon ground. The main reason for this is that a userwho is already tracking data-authenticated signalsand calculating authenticated PVT can continue

Fig. 6–MAC-K section structure

Fig. 7–Authentication data and key delay


navigating using authenticated data. Thus, when anew IODnav is transmitted by the system but notyet authenticated by the NMA generation module,the user receivers can still use the previous IOD untilthe next subframe in which the new IOD isauthenticated. This will cause no or minimaldegradation in the navigation performance during30seconds, as illustrated in Figure 8.

An authentication latency of 30 seconds wouldonly impact the case in which a user receives asubframe containing IODnav(i +1) and Auth(IODnav(i)), such as between T0+30s and T0+60sin Figure 8. For TTFAF, we can assume that thesatellites whose IODs are being updated at a giventime are a minority and that the user will still haveenough satellites in view whose IOD is not updated,therefore causing no degradation. However, in aworst-case scenario, in which the updated IODnavsatellites are necessary for the PVT and thereforefor the first fix, the usermight need to wait for anothersubframe (30seconds) to receive the newauthenticated IODnav. To overcome this, the NMAsystem module could receive a new IODnav fromE1 and E5b (which both transmit the same I/NAVmessage, but in different order) and, assuming alatency of 12 seconds, would still have time totransmit it to the user within the subframe.

Bandwidth Allocation Analysis and Comparisonwith Other NMA Proposals

This section first presents a bandwidth allocationanalysis between MAC lengths and key lengths.Based on this analysis, we select the preferredoptions for the implementation of the authenticationsolution to avoid having unused bits in the MAC-Ksections. In the current example, the following inputparameters have been considered:

• MAC-K sections total bandwidth: 480bits.• Number of MAC-K sections per subframe: 3.• Total length per MAC-K section: 160bits.• MAC header length (including IOD, SVID,

ADKD): 16bits.

With these constraints, Table 1 shows thecombinations that yield all 160 bits used, and theachievable number of MACs every 10seconds. Wecan observe that by keeping a truncated MAC length

of 10bits, and a key length of 82bits or less, 3 MACsper MAC-K section can be transmitted, for a total of9 MACs, i.e., 9 data-authenticated satellites perchannel, every 30 seconds.The full use of the 20bps of the I/NAV E1-B

‘Reserved 1’ field allows very low TBAs and a highcross-authentication redundancy, both of whichincrease robustness and performance. However, inabsolute terms, 20bps could seem high compared toother NMA solutions, so a more detailed comparisonhas been performed. AER, at least under an AWGNchannel, is not affected by bitrate. TBA is affectedby bitrate as presented in Figure 9. Figure 9assumes that 200bits between authentications arerequired, which corresponds to 160bits for theMAC-K section, and 40bits for the H-K-root sectiontransmitted in parallel.An assessment of the bandwidth allocated in other

NMA solutions proposed for the GPS constellation[2, 17] has been performed and is summarized here.These solutions define NMA authentication methodson top of the GPS CNAV messages. CNAV does notspecify a fully static message structure but definesthe minimum and maximum rates for each messagetype and also allows us to define new message typesthat can be sent in spare blocks. The rates requiredby the system are particularly demanding for theephemeris and clock data and more relaxed forother information. Each of these messages maycontain several unallocated bits. These bits togetherwith the possibility of defining new messages tocomplete the spare blocks of the CNAV allowdefinition of many different message sequencesfor future services. In summary, these GPS NMA

Fig. 8–Data-authenticatedPVTas a function of IODnav of a given satellite during IODnav transition. [Colorfigure can be viewed in the online issue, which is available at wileyonlinelibrary.com and www.ion.org]

Table 1—Number of Possible MACs for a Given MAC Lengthand Key Length Combination Using the Whole Bandwidth

Key size [bits] MAC size [bits] Number of MACs

82 10 388 20 290 19 292 18 294 17 296 16 298 15 2100 14 2102 13 2104 12 2106 11 2108 10 2


solutions define a bit allocation range between 7%and 25% of the total CNAV bandwidth, for TBAsof more than 5min down to around 100 secondsin L2-CNAV. The difference in TBA of one orderof magnitude or more compared to the proposedsolution is mainly due to the different bitrate(125bps in Galileo I/NAV versus 25bps in GPSL2-CNAV) and the reduction of authenticationbits in the proposed solution. This indicates thatthe solution herein proposed for Galileo E1B,which occupies 16.6% of bandwidth, is in the samerange as other NMA solutions in the literature, inrelative terms. Taking into account that the GalileoI/NAV message structure still has 7 out of 15 sparewords (for a total of 840 bits per subframe) and otherspare fields, and that increasing the NMAbandwidth increases TBA and therefore TTFAFand robustness, the full use of the 20bps of the‘Reserved 1’ field seems a reasonable design choice.

Time Staggering of Authentication Events

The introduction of a time offset for subsets ofsatellites to stagger the authentication verificationtimes can improve authentication robustness, asproposed in [2]. In a fully synchronous scheme with aTBA of 10seconds, all satellite information isauthenticated every 10seconds. However, receiverssubject to an attack during these 10seconds will onlydetect it when the authentication verification isperformed. If the transmission of authenticationinformation is offset for some satellites, differentsubsets of satellites would be authenticated at differenttimes, leading to a lower all-in-view TBA. The Key-to-MAC allocation proposed in this scheme must allowminimization of TBA at user level while notcompromising other parameters, and avoiding thedisclosure of the keys before or during the period whenthe associatedMACs are transmitted. Even if less thanthe four satellites required to compute a position areauthenticated at every authentication event, a receivercanmake use of the pseudorange bounds for increasingits robustness, in combination with other previously

authenticated ranges. The main features of theproposed offsetting example are as follows:

• MAC-K transmission is divided in two groups:

◦ SVID 1 to SVID 15 transmit MAC-K sectionsallowing authentication at seconds 0, 10, and 20of the subframe.

◦ SVID 16 to SVID 30 transmit delayed MAC-Ksections allowing authentication at seconds 4,14, and 24.

• MACs transmitted by SVID 1 to SVID 15 usethe key transmitted from SVID 1 (Kj,1). Thiskey can also be recovered from a key from anysatellite SVID 2 to SVID 15 transmitted at thesame time, or any key transmitted later.

• MACs transmitted by SVID 16 to SVID 30 usethe key transmitted from SVID 16 (Kj,16). Thiskey can also be recovered from a key from anysatellite SVID 16 to SVID 30 transmitted atthe same time, or any key transmitted later.

Figure 10 presents this offsetting in MAC and keytransmission scheme.

The proposed scheme authenticates half of thesatellites at 0, 10, and 20seconds, and the other halfat 4, 14, and 24seconds, leading to an all-in-viewTBA between 4 and 6seconds, with an average of5 seconds. As shown in the figure, the proposedscheme allows the simultaneous transmission of keysand MACs without compromising the system, as thetransmitted MACs always use a key that cannot becomputed from the keys under transmission.

PERFORMANCE COMPARISON

This section characterizes the proposed solution interms of AER, MPT, and USR, and assesses theimpact of adding NMA on accuracy, availability, andtime to fix. Summarizing, the characterizedimplementation is based on the following parameters:

• One MAC-K section every 10 seconds, includingone key and three MAC-K sections.

Fig. 9–Time between authentications [s] versus bandwidth [bps], assuming 200 bitsrequired between authentications. [Color figure can be viewed in the online issue, whichis available at wileyonlinelibrary.com and www.ion.org]


• Key length of 82bits.• MAC length of 10bits.• MAC-Info length of 16bits.

The characterization below excludes the processingof the H-K-root. We assumed that the receiver has anauthentic K-root.

Authentication Error Rate: As shown inEquation (1), AER depends on the bit error rate(BER) and on the number of navigation andauthentication bits (NNA) to be demodulated.BER, in turn, can be bounded by Equation (7)[32], assuming a static receiver, an AWGNchannel and stable PLL tracking:

BER ≤12� 36D10 þ 21D12 þ 1404D14 þ 11633D16� �

(7)

where

D ¼ e�C=N02Rb (8)

and Rb is the number of bits per second. The BER in(7), from which the AER is calculated, represents theaverage bit error rate at a givenC/N0, after soft decisionViterbi decoding of the Galileo I/NAV symbols [8]. Thisis the same expression used for the modernized GPSsignals and SBAS signals using the same convolutionalcode [32]. AER versus C/N0 is shown in Figure 11 forthree cases, where ADKD are ‘0’, ‘1,’ and ‘2.’

Figure 11 shows that, under these assumptions,very low AER values are obtained even at low C/N0

values. For example, an AER of 1% is obtained witha C/N0 between 25dBHz and 26dBHz for allcases. It also shows that below 24dBHz NMA isbarely usable. The authentication performance isthus as good as expected and in line with theI/NAV demodulation performance. A receiver ableto successfully demodulate the navigation datashould also be able to authenticate this data. Areceiver in an environment subject to fading mayhave problems performing authentication. However,it still can have a high NMA availability by receiving

the keys andMACs from the connected satellites withbest visibility conditions.Figure 12 shows the different error rates for

decoding just the navigation data and for decodingthe navigation plus authentication, assuming anAWGN channel. FER-1SV represents the frame errorrate (FER) of decoding only the ephemeris and clockof one satellite (words 1–4, NN=506bits). AER-1SVrepresents the authentication error rate of decodingthe same bits plus the authentication (NNA=608bitsin total). Similar reasoning applies to the 4SV and4SVI cases. 4SV implies decoding and authenticatingthe ephemeris and clock data, plus TOW, for foursatellites (NN=2044bits; NNA=2230bits) and 4SVIimplies decoding the same data as in the 4SV caseplus an additional word (Word 5) with theionospheric and BGD corrections (NN=2129bits;NNA=2341bits). Figure 12 shows that there is verylittle difference in the error rate for the receiver, withor without authentication, at a given C/N0.

Fig. 10–Key-to-MAC allocation and authentication offsetting. [Color figure can be viewed in the online issue, which is available atwileyonlinelibrary.com and www.ion.org]

Fig. 11–AER versus C/N0 for I/NAV authentication, ADKD=2(SF), ADKD=0 (eph), ADKD= 1 (iono+). [Color figure can beviewed in the online issue, which is available atwileyonlinelibrary.com and www.ion.org]


In absolute terms, and assuming that a Galileosignal processed with a receiver with a standard noisefigure and in good visibility conditions will be receivedwith a C/N0 of around 45dBHz, it can be concludedthat, even with a power loss of 18dB (from 45dBHzto 27dBHz), data authentication can be performedat a very low error rate (AER for four satellites isbelow 10�4). Therefore, taking into account that allthe data required for navigation is authenticated,the degradation of adding the proposed NMAimplementation to accuracy and availability of thestandard navigation performance will be minimal.Also, given that TBA is 10seconds and thereforesignificantly lower than the time to get a fullsubframe (30seconds), and taking into account theslight degradation in error rates, the differencebetween TTFF and TTFAF will be negligible. Onlywhen the receiver needs a new K-root at start-up,which is foreseen to occur very seldom, or when thereceiver synchronization is so loose that it needs toprocess a ‘slow MAC’, will TTFAF be higher.For comparison purposes, Figure 13 presents the

‘four satellite NA-AER’ for a given BER. It representsthe probability that four satellites are not correctlyauthenticated under a noisy channel (AWGN in thiscase), versus a given BER, for differentauthentication solutions, including the one understudy. In order to highlight the differences betweenthe authentication solutions, only the authenticationbits (i.e., NA as opposed to NNA) have beenconsidered. The TESLA solutions assume a 16-bitMAC-info section per MAC, allowing cross-authentication. The solutions analyzed are as follows:

1. AER-NA-DS-112: 466-bit digital signature, oneper satellite (112 security bits; 1864 bits needed)

2. AER-NA-STD-TESLA-112: Standard TESLAapproach, with 112-bit keys and 10-bit

truncated MACs (224 security bits; 552authentication bits needed).

3. AER-NA-1C-TESLA-112: Current concept,with 10-bit MACs and 112-bit keys (112security bits; 216 authentication bits needed).

4. AER-NA-1C-TESLA-82: Proposed implementation, with 10-bit MACs and 82-bit keys (82security bits; 186 authentication bits needed).

Cases 1, 2, and 3 use the same number of securitybits but illustrate the improvement from digitalsignatures to TESLA, and from multiple-chainTESLA to single-chain TESLA. Case 4 representsthe current proposal. One can see that between thestandard digital signature approach and the currentproposal there is an improvement of around oneorder of magnitude at low BERs.

Authentication Error Rate Including MultipleSatellites and Multiple MAC and Key Channels

The data authentication performance of theproposed solution also depends on having multiplechannels to receive redundant authenticationinformation. This section quantifies AER in this case.In the analyzed scenario, only natural impairmentsdegrade the capability of decoding the authentication(MACs, keys) and navigation information.

Let us calculate the probability of authenticating asatellite over a given time interval T. In order toauthenticate a satellite, we need the correct receptionof the navigation data (assuming it is not alreadyavailable), the key, and the MAC. Therefore, theprobability of successfully authenticating satellitel can be expressed as

PSl ¼ PMlPKPNl

¼ 1� PMl

� �1� PK

� �1� PNl

� �(9)

where PMl , PK, and PNl are the probabilities ofsuccessfully decoding a MAC for satellite l, the key,and satellite l’s navigation during T, respectively.Let us start by calculating the probability of notsuccessfully decoding a MAC of a given satellite l:

PMl ¼ MFERNMl·Cl (10)

where MFERl is the frame error rate of the MACinformation packet for satellite l, NMl is the numberof MACs that satellite l received per channel duringT, and C is the number of channels. The number ofchannels in this context is the number of connectedsatellites. In other words, the probability of notgetting a MAC for satellite l is the probability ofnot receiving any of the MACs for this satellitethat were transmitted during T from any of theC connected satellites (or channels).

Fig. 12–Error rates with and without authentication for 1 satellite,4 satellites and 4 satellites and ‘iono + ’. [Color figure can be viewedin the online issue, which is available at wileyonlinelibrary.comand www.ion.org]


We can now calculate the probability of notsuccessfully decoding any key usable to authenticatesatellite l’s MAC during T as follows:

PK ¼ 1NMK

∑NMK

i¼1KFERð Þi

� �C(11)

where NMK is the number of MAC-K sections in T,KFER is the frame error rate of the key packet (i.e.,the key, as no further information is transmitted),and C is the number of channels. The formula isexplained with an example: Let us suppose that T is30seconds (1 subframe), and NMK is three, eachMAC-Kwith one key. If satellite l’sMACwas receivedin the first MAC-K section, then it can beauthenticated with any of the three keys that willcome during T. The probability of not receivingsuccessfully any valid key is therefore (KFER)3. Ifsatellite l’s MAC was received in the second MAC-Ksection, it is (KFER)2, and if it were in the first section,it is KFER. As we do not know a priori to which sectionthe MAC belongs, all sections are treated with thesame probability 1/NMK , or 0.33. The sum of all casesis what Equation (11) provides.

Finally, we need to account for the error rate in thenavigation reception:

PNl ¼ NFERl (12)

where NFERl is the navigation frame error rate forsatellite l. We assume that it is transmitted once everyT, and only from each satellite. Otherwise, a powerfactor would be applied as for the case of the MACand the key.The plots in Figure 14 present some results for the

current implementation proposal in cases where thereare two satellites transmitting NMA (C=2, left) andwhen there is one satellite transmitting NMA (C=1,right). For simplicity, the same BER is assumed inthe calculations, even if the information may comefrom different sources.Figure 14 shows that adding authentication in

the way proposed does not degrade navigationperformance if there are two satellites transmittingauthentication information, and the degradation isminimal in the case of a single channel.Maximum Predictable Time: This parameter

depends on how the encoding and interleavingprocess of the Galileo I/NAV message encodes theunpredictable bits into symbols (some of which willbe predictable and some not) and spreads themacross the transmitted message. It turns out thatall of the unpredictable symbols of every 2-secondword are transmitted in a period of 0.4 to0.5 seconds, leaving the remaining 1.6 to 1.5 secondsfully predictable. As a reference, an MPT of1.6 seconds will be taken. This is based on theassumption that every 40-bit ‘Reserved 1’ fieldcontains unpredictable information. Since every‘Reserved 1’ field contains 32bits of a MAC-Ksection, and the longest predictable interval of aMAC-K section is the 16bits of the MAC-Info field,all the ‘Reserved 1’ fields will contain someunpredictable symbols. Test statistics to use theunpredictable symbols to protect against replayattacks are presented in [3, 6, 29].

Fig. 14–One satellite (‘1-Sat’) successful authentication probability when only the MAC & key is required(cross), and when the MAC & key & navigation is required (diamond), vs. the probability of successful receptionof navigation information (circle). Left: 2 channels; Right: 1 channel. [Color figure can be viewed in the onlineissue, which is available at wileyonlinelibrary.com and www.ion.org]

Fig. 13–Four-satellite AER versus BER. [Color figure can be viewedin the online issue, which is available at wileyonlinelibrary.comand www.ion.org]


Unpredictable Symbol Ratio: This parameteris calculated under the assumption that all symbolsare predictable except the MAC and the key bits,excluding some last bits of the key to avoid attackswhereby the last key bits are deduced andrebroadcast. The number of unpredictable symbolscan be determined as follows:

USR ¼ Klen � Kpred þ NMAC MAClen

� �NMACK

NSF

(13)

where Klen is the key length (82bits), Kpred is thenumber of key bits considered predictable, NMAC isthe number of MACs in a MAC-K section (three inour implementation), MAClen is truncated MAClength (10bits), NMACK is the number of MAC-Ksections in a subframe (three in our implementation),andNSF is the total number of symbols in a given timeperiod in which the message structure is repeated(I/NAV subframe). A Kpred of 20bits has been used.That gives a total of 276 unpredictable symbols persubframe out of a total of 7500 symbols, i.e., a USRof 3.68%. That means that on average, there are 9.2unpredictable symbols per second from which areceiver can compute an anti-replay test statistic.

FUTURE WORK

The AALECS (Authentic and Accurate LocationExperimentation with the Commercial Service) project[33] has prototyped the presented authenticationconcept and has started testing in the last months.Guidelines to understand detailed NMA imple-mentation aspects in GNSS receivers are also underdevelopment. They should include defining the levelof protection provided that some satellites in theposition solution may be not authenticated at all; onlydata-authenticated; data and TOA-authenticated,where TOA authentication has an associatedconfidence level based on a test statistic; and all these,combined with other trust measures such as AGC, J/Ndetectors, trusted clocks, inertial sensors, or antennaarrays. Another area of future work is the detailed

definition of infrastructure and processes for publickey management between the user receivers and theGalileo system.

The level of protection of NMA against replayattacks in highly degraded environments is alsocurrently under study. For the future, NMA can becombined with spreading-code authentication, forexample, in combination with Galileo E6 encryptedcodes (assuming inter-signal biases can be estimatedor are not relevant for the target authenticationapplication). The current NMA structure could bestrengthened in future Galileo satellite payloads.For example, it could be used in combination withnext generation signals watermarked at code level,as proposed in [34] with a TESLA key transmitteda few seconds later [11].

CONCLUSIONS

The Galileo program is studying the provision of anopen navigation message authentication (NMA)service in the years to come, in order to contribute tothe mitigation of GNSS vulnerabilities and provide adifferentiator with respect to other GNSS. Differentapplications could benefit from NMA to protectagainst certain spoofing attacks, used in isolation orin conjunction with inertial sensors, trusted clocks,or antenna arrays.

This article presents a concrete NMAimplementation for the Galileo Open Service. It isbased on the standard TESLA protocol modified inorder to use a single chain of keys for all satellites, toincrease robustness to data loss. The scheme isdesigned to allow cross-authentication of neighboringsatellites by a given satellite, improving availabilityin difficult visibility conditions and overcoming currentlimitations in the Galileo system.

We propose to divide the NMA structure into twomain sections: The H-K-root section to transmit aheader and a signed root key needed to initializethe authentication process, and the MAC-K sectionsto transmit the MACs and keys used regularly forauthentication. The concept follows a flexibleapproach whereby the SIS can inform the receiver

Table 2—Performance Characterization of the Proposed Authentication Solution

Indicator Result Comments

Availability No degradation Same performance as standard navigation with Galileo I/NAVAccuracy No degradation Same performance as standard navigation with Galileo I/NAVTTFAF No degradation Except when no K-root available or ‘slow MAC’ requiredTBA 10 seconds 5 seconds all-in-view TBA if authentication events are offsetMPT ~1.6 seconds Every 2 seconds, 40 authentication bits, out of which some are unpredictable, are

transmittedUSR 3.68% (of total) Assuming 276 unpredictable symbols every 30 seconds.

23% (of auth.) 3.68% of total I/NAV symbols (7500 per subframe)23% of authentication symbols (1200 per subframe)

AER See Figure 11, Figure 12, Figure 14,Figure 13

No or minimal degradation with respect to standard navigation


about the MAC and key sizes for new chains,allowing maintenance of high system robustnessduring the system lifetime even in the case ofcomputational and cryptanalysis progresses.

The proposed solution is then characterized,mainly interms of TBA and AER, which in turn affect availability,accuracy, and TTFAF (time to first authenticated fix).The results show that the proposed implementation doesnot degrade the performance of a data-authenticateduser with respect to a standard user.

The paper also characterizes NMA unpredictabilityas a relevant design parameter to be maximized.Anti-replay protection is taken into account in thedesign by the parameters MPT and USR. Table 2summarizes the performance of the NMA proposal forGalileo I/NAV.

Based on the presented results, and notwithstandingany improvements that may be incorporated in thefuture, we can conclude that Galileo, through itsI/NAV E1-B signal, can provide a highly available androbust NMA service.

ACKNOWLEDGMENTS

The authors would like to especially thank P.Walker and A. Kerns for their insightful comments,the Journal anonymous reviewers for their reviews,H. Tork, the other AALECS team members involvedin authentication (C. Holmes, E. Carbonell, O.Pozzobon, S. Fantinato, M. Canale), C. Wullems, R.Ioannides, T. Humphreys, F. Diani, J. Marechal,and the GNSS team at JRC-IPSC, A6 Unit.

DISCLAIMER

The material in this paper does not represent anyofficial view of the EU or its Member States. Thesolutions proposed are subject to modifications andwill not necessarily be included in future Galileooperational services.

REFERENCES

1. John A. Volpe National Transportation SystemsCenter, “Vulnerability Assessment of the TransportInfrastructure Relying on the Global PositioningSystem,” U.S. DoT, 2001.

2. Wesson, K., Rothlisberger, M., and Humphreys, T.,“Practical Cryptographic Civil GPS SignalAuthentication,” NAVIGATION, Vol. 59, No. 3, Fall2012, pp. 177–193.

3. Günther, C., “A Survey of Spoofing and Counter-Measures,” NAVIGATION, Vol. 61, No. 3, Fall 2014,pp. 159–177.

4. Wullems, C., Pozzobon, O., and Kubik, K., “SignalAuthentication and Integrity Schemes for NextGeneration Global Navigation Satellite Systems,”Proceedings of the European Navigation Conference, 2005.

5. Perrig, A., Canetti, R., Tygar, J. D., and Song, D.,“The TESLA Broadcast Authentication Protocol,”CryptoBytes, Vol. 5, No. 2, Summer/Fall 2002,pp. 2–13.

6. Humphreys, T., “Detection Strategy for CryptographicGNSS Anti-Spoofing,” IEEE Transactions onAerospace and Electronic Systems, Vol. 49, No. 2,2013, pp. 1073–1090.

7. The US Government, “GPS Interface SpecificationIS-GPS-200,” 2014.

8. European Union, “OSSISICD: Open Service Signal InSpace InterfaceControlDocument, Issue 1.1,”September2010.

9. Calle, J. D., Carbonell, E., Rodríguez, I., Tobías, G.,Göhler, E., Pozzobon, O., Cannale, M., and Fernández,I., “Galileo Commercial Service from the EarlyDefinition to the Early Proof-Of-Concept,” Proceedingsof the 27th International Technical Meeting of the SatelliteDivision of The Institute of Navigation (ION GNSS+2014), Tampa, FL, September 2014, pp. 392–405.

10. Fernández-Hernández, I., “Authentication: DesignParameters and Service Concepts,” Proceedings ofthe European Navigation Conference, 2014.

11. Fernandez-Hernandez, I., Rijmen, V., Seco-Granados,G., Simón, J., and Rodríguez, I., “Design Drivers,Solutions and Robustness Assessment of NavigationMessage Authentication for the Galileo OpenService,” Proceedings of the 27th InternationalTechnical Meeting of the Satellite Division of TheInstitute of Navigation (ION GNSS+ 2014), Tampa,FL, September 2014, pp. 2810–2827.

12. National Institute of Standards and Technology, “FIPSPUB 180-4: Secure Hash Standard (SHS),” 2012.

13. Lamport, L., “Password Authentication with InsecureCommunication,”Communications of the ACM, Vol. 24,No. 11, November 1981, pp. 770–772.

14. Walker, P., Rijmen, V., Fernandez-Hernandez, I.,Simón, J., Calle, D., Pozzobon, O., and Seco-Granados,G., “Galileo Open Service Authentication: A CompleteService Design and Provision Analysis,” Proceedings ofthe 28th International Technical Meeting of the SatelliteDivision of The Institute of Navigation (ION GNSS+2015), Tampa, FL, September 2015, pp. 3383–3396.

15. Lo, S. and Enge, P., “Authenticating AviationAugmentation System Broadcasts,” Proceedings ofIEEE/ION PLANS 2010, Indian Wells, CA, May2010, pp. 708–717.

16. Curran, J. T., Paonni, M., and Bishop, J., “Securingthe Open-Service: A Candidate Navigation MessageAuthentication Scheme for Galileo E1 OS,”European Navigation Conference ENC 2014,Rotterdam, 2014.

17. Kerns, A. J., Wessons, K., and Humphreys, T., “ABlueprint for Civil GPS Navigation MessageAuthentication,” Proceedings of IEEE/ION PLANS2014, Monterey, CA, May 2014, pp. 262–269.

18. Fernández-Hernández, I. “Method and system tooptimise the authentication of radionavigationsignals,” WO/2015/154981, Filed by the EuropeanUnion. 8 Apr. 2014.

19. National Institute of Standards and Technology,“FIPS PUB 198-1: The Keyed-Hash MessageAuthentication Code (HMAC),” 2008.


20. International Organization for Standardization, “ISO/IEC 9797-1:2011: Information Technology - SecurityTechniques - Message Authentication Codes (MACs) -Part 1: Mechanisms Using a Block Cipher,” 2011.

21. Menezes, A., Van Oorschot, P., and Vanstone, S.,Handbook of Applied Cryptography, CRC Press,Inc., Boca Raton, FL, USA, 1996.

22. Guilford, J., Yap, K., and Gopal, V., “Fast SHA-256Implementations on Intel Architecture Processors,”IA Architects, 2012. Available: http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/sha-256-implementations-paper.pdf.

23. Krawczyk, H., Bellare, M., and Canetti, R., “HMAC:Keyed-Hashing for Message Authentication,” NetworkWorking Group, United States, 1997.

24. Lenstra, A. K., “Key Lengths, Contribution to TheHandbook of Information Security,” Lucent Technologiesand Technische Universiteit Eindhoven, 1 North GateRoad, Mendham, NJ 07945-3104, U.S.A., 2004.

25. ECRYPT, “Yearly Report on Algorithms and Keysizes,”2012. Available: http://cordis.europa.eu/docs/projects/cnect/6/216676/080/deliverables/002-DSPA20.pdf.

26. ENISA, “Algorithms, Key Sizes and ParametersReport - Recommendations,” 2013.

27. National Institute of Standards and Technology, “SP800-131A: Transitions: Recommendation forTransitioning the Use of Cryptographic Algorithmsand Key Lengths,” 2011.

28. National Institute of Standards and Technology,“DRAFT FIPS PUB 202: SHA-3 Standard:Permutation-Based Hash and Extendable-OutputFunctions,” 2014.

29. Fernández-Hernández, I., “Snapshot andAuthenticationTechniques For Satellite Navigation,” Faculty ofEngineering and Science, Aalborg University, June2015.

30. International Organization for Standardization,“ISO/IEC 9796-3. Information Technology – SecurityTechniques – Digital Signatures Giving MessageRecovery – Part 3: Discrete Logarithm BasedMechanisms,” 2006.

31. International Organization for Standardization,“ISO/IEC 14888-3: Information Technology - SecurityTechniques - Digital Signatures With Appendix - Part3: Discrete LogarithmBasedMechanisms - Amendment1,” 2009.

32. Kaplan, E. and Hegarty, C., Understanding GPSPrinciples and Applications, Artech House, Inc.,Boston & London, 2006.

33. Rodríguez, I., Tobías, G., Calle, D., Martín, J.,Pozzobon, O., Canale, M., Maharaj, D., Walker, P.,Göhler, E., Toor, P., and Fernández-Hernández, I.,“Preparing for the Galileo Commercial Service – Proofof Concept and Demonstrator Development,”Proceedings of the 27th International Technical Meetingof the Satellite Division of The Institute of Navigation(ION GNSS+ 2014), Tampa, FL, September 2014,pp. 3399–3410.

34. Scott, L., “Anti-Spoofing & Authenticated SignalArchitectures for Civil Navigation Systems,”Proceedings of the 16th International TechnicalMeeting of the Satellite Division of The Institute ofNavigation (ION GPS/GNSS 2003), Portland, OR,September 2003, pp. 1543–1552.


a navigation message authentication proposal for the...

Documents