SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
by
Ignacio Fernández Hernández
Dissertation submitted to the Faculty of Engineering and Science at Aalborg University
in partial fulfilment of the requirements for the degree of
Doctor of Philosophy in Electrical Engineering.
I SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Thesis submitted: May 7th, 2015
PhD supervisors: Prof. Kai Borre,
Aalborg University
Prof. Torben Larsen,
Aalborg University
PhD committee: Prof. Per K. Enge, Stanford University
Dr. Frank van Diggelen, Broadcom Corporation
Prof. Søren Holdt Jensen, Aalborg University
PhD Series: Faculty of Engineering and Science, Aalborg University
II ENGLISH SUMMARY
Since GPS was declared fully operational in 1995, satellite navigation technologies have evolved in many ways. Two of them are the drivers for this doctoral thesis: satellite navigation authentication and snapshot positioning techniques.
The first research area of this thesis is GNSS authentication. In spite of the high importance of GNSS in our society and economy, its civil signals are easy to counterfeit. This thesis proposes novel techniques and concepts, such as satellite cross-authentication, single key chains for all satellites, and offsetting schemes, to improve the performance of navigation message authentication. It presents and analyses a solution requiring less than two hundred bits for authenticating four satellites, providing high availability and robustness.
The second research area of this thesis is snapshot positioning. Snapshot techniques are based on computing a position using only a set of digital signal samples captured over some milliseconds. Existing techniques require a rough knowledge of the position and/or time at which the snapshot was captured. This thesis proposes and characterizes a novel method to instantaneously compute a snapshot position without any initial information. The proposed method does not cause any accuracy or availability degradation compared to other state-of- the-art snapshot methods.
In relation to the previous area, this thesis also deals with the generalization of the snapshot positioning concept to non-GNSS satellites. By using more powerful signals from non-GNSS satellites, indoors localization and resilience can be improved. This thesis proposes a method based on a ground network that processes non-GNSS satellite signal snapshots and is able to compute from them the instantaneous position and other reference parameters of those satellites. Thus, a receiver can get a fix by receiving its own snapshot and the associated instant satellite parameters from the ground network. Experimentation shows that, depending on the satellite-ground geometry and signal characteristics, metre-level accuracies are possible with this method.
This thesis also presents some research initial on the combination of authentication and snapshot positioning. Snapshot authentication methods based on a trusted clock and geometrical constraints are proposed to authenticate unpredictable signals through snapshot techniques.
III SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
DANSK RESUME
GPS blev erklæret fuldt operationelt i 1995. Siden da har teknologien bag satellit navigation udviklet sig på mange måder. To af dem er drivkraften bag denne Ph D afhandling: troværdighed (på engelsk: authentication) af satellitbaseret navigation og metoder for snap- shot positionering.
Det første forskningsområde i denne afhandling vedrører troværdigheden af GNSS. På trods af den store betydning af GNSS i vores samfund og økonomi er det let at forfalske de civile signaler. Denne afhandling foreslår nye teknikker og begreber -- som kryds-troværdighed mellem satellitter, signatur for alle satellitter og forskydningstabeller -- for at sikre troværdigheden af navigationsdata. Den fremlægger og analyserer en løsning, der kræver mindre end to hundrede bits for at gøre fire satellitter troværdige, tilvejebringe høj tilgængelighed og robusthed.
Afhandlingens andet forskningsområde vedrører snap-shot positionering. Snap-shot metoder beregner en position udelukkende på grundlag af et sæt signaler hver af en varighed på få millisekunder. Eksisterende metoder kræver kendskab til position og/eller det tidspunkt, hvor snap-shottet blev indsamlet. Denne afhandling foreslår og karakteriserer en hidtil uset metode til øjeblikkeligt at beregne en snap-shot position uden nogen forudgående information. Den foreslåede metode indebærer ikke forringet nøjagtighed eller tilgængelighed sammenlignet med de mest avancerede snap-shot metoder.
I tilknytning til det foregående emne indeholder denne afhandling også en generalisering af snap-shot positionering, så den omfatter ikke-GNSS satellitter. Ved at anvende kraftigere signaler fra ikke-GNSS satellitter kan man forbedre indendørs lokalisering og den tilknyttede robusthed. Denne afhandling foreslår en metode -- baseret på et jordbaseret net -- som beregner snap-shots fra ikke-GNSS satellitter og er i stand til også at beregne en øjeblikkelig position og andre reference parametre for disse satellitter. Herved kan en bruger beregne en position ved at modtage sit eget snap-shot og de tilknyttede øjeblikkelige satellit parametre fra det jordbaserede net. Eksperimenter viser, at afhængig af satellit-jord geometrien og signal egenskaberne er det muligt at opnå meter nøjagtighed med denne metode.
IV Et fjerde forskningsområde, der sættes i gang i denne afhandling, er kombinationen af troværdighed og snap-shot positionering. Der foreslås en snap-shot metode, der baserer sig på en pålidelig ekstern ur-reference, hvorved uforudsigelige signaler kan gøres troværdige gennem snap-shot teknikker.
V
ACKNOWLEDGEMENTS
First, I would like to thank my supervisors Prof. Kai Borre and Prof. Torben Larsen, from AAU, for facilitating so much the process of preparing my PhD candidature. Prof. Borre has given me very valuable strategic advice and a lot of technical and moral support over these years, and Prof. Larsen has helped me a lot on the home strait of the thesis. Both have given me their trust and a lot of flexibility in the orientation the research activities, which I highly appreciate.
I would like to give specially thanks Prof. Gonzalo Seco-Granados, for his generosity and patience in sharing some of his vast knowledge and perspicacity with me. His help extends throughout all the research in this thesis, including both snapshot and authentication areas. He has provided many useful references and suggestions, especially, but not only, on signal-related aspects.
The work on authentication relates to my job duties and my job colleagues have partly supported it. I have been luckily surrounded by very good engineers “helping the cause” of authenticating Galileo in a selfless, constructive and collaborative way, reviewing and discussing material and making insightful comments. I would like to thank Prof. Vincent Rijmen for providing many references and recommendations used in this thesis concerning the cryptographic parts and for being available to share his insight during our long discussions. I also appreciated Dr. Paul Walker's critical review and useful suggestions. The review and sharp comments from Andrew Kerns and Prof. Todd Humphreys have been also very valuable. Javier Simón, Guillermo Tobías, David Calle, Enrique Carbonell and Irma Rodríguez, with the support of Oscar Pozzobon, Laurens Bogaardt and Dominic Hayes, have also significantly contributed to improving the quality of our publications on the subject. In addition, I would like to thank my colleagues at EC/GSA Fiammetta Diani, Jean Marechal and Eric Châtre for their determination and support.
On the snapshot research area, I would like to thank Oriol Badia for giving me access to some of the snapshot data captures and Matlab code from his Master's Thesis at AAU. I would also like to thank Michele Bavaro for kindly lending me one of his SDRs, and Darius Plaušinaitis.
6
Dr. Frank van Diggelen's A-GPS book, Prof. Enge's GPS book, and Prof. Borre's GNSS SDR book are the three main references that have allowed me to “triangulate” and find my way through this thesis, with the regular assistance channel of Prof. Seco. I am highly privileged in having Dr. van Diggelen and Prof. Enge, together with Prof. S. J. Jensen, in my PhD assessment committee. I would like to thank them for their availability and inspirational contributions, without which this thesis would not probably have been even started.
Finally, but most importantly, I would like to thank Paloma, my wife, for her continuous support during this journey.
The information and views set out in this dissertation are those of the author and do not necessarily reflect the official opinion of the European Union.
7 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
TABLE OF CONTENTS
Chapter 1. Introduction ...... 17 1.1. Scientific Challenges and Main Contributions...... 17
1.2. Thesis Outline ...... 20
Chapter 2. General Technical Background ...... 21 2.1. A Brief History of Navigation ...... 21
2.2. Radionavigation Methods ...... 24
2.2.1. Satellite Navigation Systems and Signals ...... 25
2.2.2. Satellite Navigation Receivers ...... 28
2.3. A Brief History of Cryptography ...... 29
2.3.1. Modern Cryptography and Asymmetric Algorithms ...... 31
2.3.2. GNSS and Cryptography ...... 33
Chapter 3. Navigation Message Authentication ...... 36 3.1. Motivation ...... 36
3.2. Background ...... 37
3.2.1. Information Security Management Systems (ISMS) ...... 37
3.2.2. Standards ...... 38
3.2.3. GNSS Positioning Threats ...... 40
3.2.4. Detection and Mitigation Actions ...... 41
3.2.5. Detection and Mitigation based on GNSS Signal Properties...... 42
3.2.6. Summary ...... 43
3.3. User Needs, High Level Requirements and Design Drivers ...... 43
3.4. Performance Indicators ...... 46
3.4.1. Authentication Error Rate ...... 48
3.4.2. Time Between Authentications ...... 49
8
3.4.3. Robustness against Replay Indicators: Maximum Predictable Time and Unpredictable Symbol Ratio ...... 50
3.4.4. Other Robustness Indicators ...... 51
3.5. Proposed GNSS Authentication Concept ...... 51
3.5.1. The TESLA Protocol Features ...... 51
3.5.2. TESLA with a Single Chain from Several Senders ...... 54
3.5.3. TESLA with a Single Chain and Different Keys from Different Senders ...... 55
3.5.4. TESLA and "Cross-Authentication" ...... 58
3.6. An NMA Proposal for Galileo Signals ...... 59
3.6.1. H-K-root Section ...... 62
3.6.2. MAC-K Sections ...... 65
3.6.3. Bandwidth Allocation Analysis ...... 69
3.7. A Proposed Implementation in the Galileo System and Facilities ...... 70
3.7.1. NMA Architecture ...... 70
3.7.2. System Latency and User Performance ...... 71
3.7.3. Message Losses ...... 75
3.7.4. Downlink Requirements ...... 76
3.7.5. NMA of Data from Other GNSS ...... 77
3.8. Design Trade-Offs ...... 77
3.8.1. Cross-Authentication of Neighbouring Satellites ...... 78
3.8.2. Digital Signatures vs. Time-Delayed Asymmetry ...... 80
3.8.3. Staggering of Authentication Events ...... 81
3.8.4. Security Considerations ...... 83
3.8.5. Receiver CPU Needs ...... 85
3.9. Performance Results...... 86
3.9.1. NMA Availability and AER ...... 86
3.9.2. Time To First Authenticated Fix ...... 100
3.9.3. Performance Assessment in Urban Environments – A Practical Case ...... 103
9 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
3.9.4. Assumptions for satellites transmitting NMA ...... 106
3.9.5. Assumptions for satellite MAC sequence ...... 106
3.10. Signal Unpredictability and Anti-Replay Protection ...... 108
3.10.1. USR and Predictability of the Last Bits of the Key ...... 109
3.10.2. Symbol Unpredictability and MPT after Encoding and Interleaving ...... 111
3.10.3. Detection of Signal Replay Attacks Based on NMA ...... 115
3.11. Conclusions ...... 120
Chapter 4. Snapshot Positioning Without Initial Information ...... 123 4.1. Motivation ...... 123
4.2. Background ...... 124
4.2.1. Snapshot Positioning ...... 124
4.2.2. Snapshot Signal Acquisition and Measurement Accuracy ...... 126
4.2.3. Snapshot Synchronisation ...... 127
4.2.4. Code Phase Ambiguity Resolution ...... 128
4.3. General Description of the Proposed Algorithm ...... 129
4.3.1. "Cold Snapshot" Equations for a Static Receiver ...... 132
4.3.2. "Cold Snapshot" Equations for a Dynamic Receiver...... 133
4.4. General Algorithm Implementation Including Long Time Uncertainty Periods . 134
4.4.1. Orbital Repeatability and Advantages of Multi-GNSS ...... 137
4.4.2. "Cold Snapshot" with Coarse Time Pseudorange Navigation ...... 140
4.4.3. Hardware Implementations and Applications of the Proposed Algorithm .... 141
4.5. Experimental Results ...... 142
4.5.1. Configuration ...... 143
4.5.2. Signal Acquisition ...... 144
4.5.3. Coarse Time Doppler Stage ...... 147
4.5.4. Coarse Time Navigation and Final PVT Calculation ...... 149
4.5.5. Results ...... 149
4.6. Conclusions ...... 152
10
Chapter 5. Generalisation of Snapshot Positioning ...... 154 5.1. Motivation ...... 154
5.2. Background ...... 156
5.2.1. Overview of non-GNSS Constellations, Satellites and Signals ...... 156
5.2.2. Background on Positioning with Non-GNSS Satellites ...... 158
5.3. Signal and Error Model ...... 159
5.3.1. Ranging Accuracy Estimation Through the CRLB ...... 161
5.4. Description of the Method ...... 162
5.4.1. Capture of User Receiver Snapshot ...... 163
5.4.2. Capture of Snapshot at Monitor Stations ...... 165
5.4.3. Signal Acquisition and Satellite Range Estimation ...... 167
5.4.4. Instantaneous Satellite Position and Clock Calculation ...... 169
5.4.5. Satellite Velocity and Frequency Drift Calculation ...... 171
5.4.6. Reference Parameters for at Least Four Satellites...... 171
5.4.7. User Receiver Position Calculation ...... 172
5.5. Experimental Results: One Satellite Snapshot Positioning ...... 172
5.5.1. Configuration ...... 173
5.5.2. Simulator Steps ...... 176
5.5.3. Signal Acquisition and Parameter Estimation ...... 177
5.5.4. Satellite PVT Computation ...... 178
5.5.5. Results ...... 178
5.6. Experimental Results: User Snapshot Positioning Based on Satellite Snapshot Positioning ...... 180
5.6.1. Configuration ...... 180
5.6.2. Simulator Steps ...... 184
5.6.3. Results ...... 184
5.7. Conclusions ...... 187
Chapter 6. Conclusions and Further Work ...... 189 6.1. Further Work ...... 190
11 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
6.1.1. GNSS Authentication...... 190
6.1.2. Cold Snapshot ...... 191
6.1.3. Snapshot Generalisation...... 191
6.1.4. Snapshot Authentication ...... 192
Literature list ...... 193 Appendices ...... 203
12
TABLE OF FIGURES
Figure 1 – John Harrison's portable Chronometer H5 ...... 22 Figure 2 –LEO, MEO and GEO satellite orbital radiuses, periods and speeds ...... 25 Figure 3 – Satellites in view foreseen at Aalborg, 23/6/2015, 12:00 (CET) ...... 26 Figure 4 – GNSS signals ...... 27 Figure 5 – GNSS receiver blocks ...... 28 Figure 6 – Symmetric systems: diagram (left) and Enigma machine with four rotors (right) ...... 30 Figure 7 – Asymmetric Cryptography for Confidentiality (left) and Authentication (right) ...... 32 Figure 8 - Authentication Performance Framework ...... 46 Figure 9 – TESLA one-way chain of keys ...... 52 Figure 10 – Standard TESLA approach with a different key and chain per sender ...... 54 Figure 11 – TESLA approach with the same key for all senders ...... 55 Figure 12 – TESLA one-way chain with different keys from different senders ...... 57 Figure 13 – TESLA single-chain approach with a different key transmitted by each sender. No cross-authentication...... 57 Figure 14 – TESLA single-chain approach with connected (2,4) and non-connected (1, 3, 5) satellites ...... 58 Figure 15 – Galileo E1B I/NAV subframe message structure ...... 60 Figure 16 – "Reserved 1" field in each I/NAV Word ...... 61 Figure 17 –NMA proposal within the Galileo I/NAV message structure ...... 62 Figure 18 – H-K-root structure and fields (see Appendix B for more details)...... 63 Figure 19 – H-K-root example in five subframes/blocks ...... 64 Figure 20 – H-K-root / header / number of blocks field...... 64 Figure 21 – MAC-K section structure (see Appendix B for more details) ...... 65 Figure 22 – NMA Architecture ...... 71 Figure 23 – Authenticated PVT as a function of IODnav of a given satellite during IODnav transition ...... 72 Figure 24 –"Optimised" authentication transmission to authenticate IODnav from the same subframe (eph&clock I/NAV words 1, 2, 3, 4 marked in grey) ...... 74 Figure 25 – Schematic of the cross-authentication approach ...... 78
13 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 26 – Out of view satellites in cross-authentication ...... 79 Figure 27 – Key-to-MAC allocation and authentication offsetting ...... 82 Figure 28 – (Maximum) BER of Galileo I/NAV E1-B vs C/N0, AWGN channel ...... 88
Figure 29 –AER vs C/N0 , ADKD=0 ('eph&clk', blue), 1 ('ionoBGD',red), 2 ('SF',green) ...... 89 Figure 30 – Error rates with and without authentication for 1 satellite, 4 satellites and 4 satellites and 'ionoBGD' ...... 90 Figure 31 – Error rates with and without authentication for 1 satellite, 4 satellites and 4 satellites and 'ionoBGD' – Zoom around 26 dBHz C/N0 (ii) ...... 91 Figure 32 – Four-satellite AER vs BER ...... 92 Figure 33 – Probability of successfully authenticating one satellite (S) (i.e. 1 – AER) when only the MAC & key is required (blue), and when the MAC & key & navigation is required (red), vs. the probability of successful reception of navigation information (black). Top: Nominal-2C Scenario; Middle: Nominal-1C Scenario; Bottom: Worst-Case Scenario ...... 97 Figure 34 – Probability of data authenticated position (PVT) vs. BER, for 4 to 9 satellites in view, based on S without navigation reception. Top: Nominal-2C Scenario; Middle: Nominal-1C Scenario; Bottom: Worst Case Scenario ...... 99 Figure 35 – Probability of data authenticated position (PVT) vs. BER, for 4 to 9 satellites in view, based on S including navigation reception. Top: Nominal-2C Scenario; Middle: Nominal-1C Scenario; Bottom: Worst Case Scenario ...... 100 Figure 36 – Masking vs. azimuth and elevation sky plot - Urban Environment, using GNSS Planning Online tool [60] ...... 104 Figure 37 – Satellite view, 48.8567° N, 2.3508° E, 30 GPS satellites, 1/4/2015, using GNSS Planning Online tool [60] ...... 105 Figure 38 – Sky plot at 1/4/2015, 10:20:00, using GNSS Planning Online tool [60] .... 105 Figure 39 – Time to compute the remaining bits of a key (휏푗) compared to the time between unpredictable symbols (휏퐵푈푆) ...... 111 Figure 40 – Galileo I/NAV convolutional encoding [12]...... 112 Figure 41 – Probability of error in the estimation of an unpredictable symbol wrt. Integration time (M*Ts), for different C/(N0 + I0) values ...... 117 Figure 42 – Minimum Gain Reduction when spoofed (Maximum spoofed vs non-spoofed gain), vs. Integration Time (M*Ts) ...... 119 Figure 43 – Satellite range rate variation over time ...... 130
14
Figure 44 – Satellite-to-receiver acceleration estimated as range-rate variation over time ...... 131 Figure 45 – Range rate (i.e. the sign-reversed Doppler shift), and relative acceleration over a satellite pass. Relative acceleration can be approximated by a constant ...... 131 Figure 46 – Logic flow diagram of the "cold snapshot" algorithm ...... 135 Figure 47 – "Cold snapshot" algorithm run for different periods ...... 138 Figure 48 - Low-residual GPS orbital repeatability – 12-hour effect ...... 139 Figure 49 – "Cold snapshot" algorithm run for different periods with different GNSS to avoid low-residual wrong solutions due to satellite orbital repetition ...... 139 Figure 50 – Pseudorange solution residual computation to determine the right "cold snapshot" solution...... 140 Figure 51 – Logic flow diagram of the "cold snapshot" algorithm combined with coarse time navigation ...... 141 Figure 52 –Receiver-server implementation of "cold snapshot" ...... 142 Figure 53 – Block diagram of Code phase parallel acquisition [13] ...... 145 Figure 54 - Quadratic Peak Interpolation - Sample '1' corresponds to the peak. Sampling Frequency = 16.368e6. GPS PRN 2 in ID6 data capture, first snapshot...... 146 Figure 55 - Instantaneous Doppler Positioning for scenario ID2 (DGC). Instantaneous Doppler solutions are calculated once every minute. Top-left: Doppler measurement residuals vector module. Top-right: Position error. Bottom left: Estimated frequency drift. Bottom right: Estimated position height...... 148 Figure 56 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold snapshot" results - Scenario ID2 - Danish GPS Centre, Aalborg. 2DRMS means RMS in 2 Dimensions (horizontal RMS) ...... 150 Figure 57 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold snapshot" results - Scenario ID6 - UAB, Barcelona...... 151 Figure 58 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold snapshot" results - Scenario ID3 – CTAE, Barcelona ...... 151 Figure 59 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold snapshot" results - Scenario ID5 – Gallecs, Barcelona. 2DRMS error means RMS error in two horizontal dimensions...... 152 Figure 60 – Operational, Partly Operational and Spare Satellites, Apr. 2015 - source: Spacebook...... 155
15 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 61 – Maximum accuracy achievable (standard deviation) according to Cramér- Rao Lower Bound for different signal to noise density ratios and chip frequencies. 1- milisecond integration time ...... 162 Figure 62 – User receiver signal snapshot – Asynchronous case ...... 164 Figure 63 – User receiver signal snapshot – Synchronous case ...... 165 Figure 64 - Satellite signal snapshot reception by a ground monitor network ...... 166 Figure 65 – Example of satellite signal time of arrival at different monitor stations (m1, m5) ...... 168 Figure 66 – Example of sliding window for snapshot acquisition. Highest correlation at w5...... 169 Figure 67 – Diagram showing the information available to the user: position(t0), velocity(t0), bias(t0), frequency drift and signal sequence to correlate from at least four satellites ...... 172 Figure 68 – Snapshot satellite positioning – Satellite and Ground monitor positions (Google Earth) ...... 174 Figure 69 - Monitor snapshot generation: signal samples for one signal at 6 monitor stations. C/N0 = 70 dBHz. Fs = 16.7439 MHz ...... 177 Figure 70 – Satellite position 3D error [m] and RMS-3D...... 179 Figure 71 – Satellite position 3D error [m] in XYZ coordinates...... 179 Figure 72 – Snapshot ground segment, including 6 stations and a test user...... 181 Figure 73 – Ground segment, space segment, and user segment ...... 183 Figure 74 – User horizontal (2D) and 3D position error and RMS error ...... 186 Figure 75 – User horizontal position error (X=East; Y=North) ...... 186 Figure 76 – DSM field options ...... 213 Figure 77 - User terminal, time reference and spoofer ...... 230 Figure 78 - Reduction of solution space with height estimation ...... 231
16
Chapter 1. Introduction
As our lives become more dependent on satellite navigation, the threats to GPS and its signals become potentially more harmful. GNSS (Global Navigation Satellite System) signals are weak and can be easily jammed and spoofed. To increase resilience of GNSS, some research over the last years has studied concepts to both authenticate the GNSS data and signals, and to increase PNT (Position, Navigation and Timing) resilience by using other technologies. Within this area of research, this thesis focuses on NMA (Navigation Message Authentication), and analyses its implementation for Galileo, the European GNSS. The first part of this thesis devoted to this topic.
Thanks to the progress in the semiconductor industry, more and more functions of GNSS receivers can be written in software and performed by a general CPU in real time. This includes the computation of a position from a digital snapshot of data, without the need to track the signals and decode their data. This thesis proposes an algorithm to improve snapshot positioning allowing a position solution to be computed without any information about when or where the snapshot was captured. It also generalizes snapshot positioning to its application to signals from satellites other than GNSS. This is the subject of the second part of the thesis. At the end of the thesis, an annex is devoted to snapshot authentication, that is, the combination of the two areas.
1.1. Scientific Challenges and Main Contributions
This section presents the principal thesis contributions and the problems they intend to solve.
The first challenge in the authentication area has been to define a framework with the key performance indicators for designing and comparing authentication solutions. This thesis proposes a simple yet useful performance framework for this purpose. The main scientific and engineering challenge in the authentication area has been the design of an NMA solution that is robust and highly available. For this, novel concepts such as the authentication through one key for all satellites based on the TESLA (Timed Efficient Stream Loss-Tolerant Authentication) protocol; TESLA authentication through one chain
17 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION and different keys for all satellites; or cross-authentication, are proposed. Based on the above concepts, the thesis proposes a cryptographically robust solution requiring less than 200 bits for authenticating four satellites, which facilitates authentication even in difficult environments compared to standard digital signatures, which would require around 2000 bits for a similar security level. An average Time Between Authentications (TBA) of 5 seconds at user level, at 20 authentication bits per second, can be achieved. This reduces receiver coasting time and improves NMA robustness.
The work for this thesis has also led to the first end-to-end bit-level public proposal of an open NMA service in a GNSS, particularised for the Galileo I/NAV message “Reserved 1” field, with all data fields required for a potential operational implementation, including operational modes, key management fields, user notification flags, on-the-fly configuration parameters, etc. The solution allows on-the-fly modification of the sizes and functions of chains, keys, MACs and digital signatures, allowing to maintain security through a long operational lifetime.
Understanding the protection against replay attacks that an NMA solution offers is also a challenge tackled in the GNSS authentication literature and partly in this thesis. This thesis characterises the replay detection capabilities of NMA in a receiver based on signal processing of the first samples of unpredictable symbols.
The main scientific contribution of the snapshot research area is a novel snapshot navigation method (named "cold snapshot" in the thesis) to calculate a position and timing solution of a snapshot without any initial conditions. This method allows calculating positions based on snapshots unrelated to any position or time reference. It allows time uncertainties of several days or weeks to be resolved instantaneously, without any position reference, and without accuracy degradation. The thesis presents an algebraic description of the algorithm and validates its performance with real data.
The second principal contribution in the snapshot domain is the definition of a method to generalise snapshot positioning for non-GNSS satellites. Through this method, receivers could ideally use all satellites in view (not only GNSS) for an instantaneous position solution. An end-to-end simulator has been developed to prove the concept and assess its performance.
Out of the above, the contributions of the thesis considered as the most significant are:
18
The “cold snapshot” algorithm (section 4.3). A generalisation of snapshot positioning (section 5.4). One-key and one-chain TESLA approaches including cross-authentication (sections 3.5.2 to 3.5.4). An exhaustive analysis of an NMA implementation proposal in a GNSS (sections 3.6 to 3.10).
The work of this thesis has led to the following publications and patent applications:
I. Fernández Hernández, “GNSS authentication: design parameters and service concepts”, European Navigation Conference 2014, Rotterdam, April 2014, n.150. I. Fernández Hernández, V. Rijmen, G. Seco-Granados, J. Simón, I. Rodríguez, D. Calle, “Design Drivers, Solutions and Robustness Assessment of Navigation Message Authentication for the Galileo Open Service”, Proceedings of ION GNSS+ 2014, Tampa, Florida, September 2014 I. Fernández Hernández, V. Rijmen, G. Seco-Granados, J. Simón, I. Rodríguez, D. Calle, “A Navigation Message Authentication Proposal for the Galileo Open Service”, Journal of the Institute of Navigation. Currently under review. EP13175821, Digitally signed satellite radio-navigation signals, Ignacio Fernández Hernández, The European Union, represented by The European Commission. –related to a specific implementation for the Galileo system- EP14163902, Method and system to optimise the authentication of radionavigation signals, Ignacio Fernández Hernández, The European Union, represented by The European Commission. –related to a specific implementation for the Galileo system- GB1412351.7, Method and apparatus for instantaneous positioning and timing without initial information, Ignacio Fernández Hernández, Kai Borre.
The results presented in this thesis are reproducible. The work in this thesis includes the following software developments:
A Matlab snapshot GPS L1 C/A receiver (section 4.5). A Matlab end-to-end snapshot signal and system simulator, including space, ground and user segments (sections 5.5 and 5.6). A set of Matlab scripts to analyse NMA performance (section 3.9).
19 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
1.2. Thesis Outline
Chapter One presents the general introduction to the thesis and the main contributions.
Chapter Two presents a general technical introduction to the main subjects of the thesis, by providing a general overview of satellite navigation systems and receivers, and an introduction to cryptography.
Chapter Three presents the work on GNSS navigation message authentication.
Chapter Four presents the work on snapshot positioning techniques without initial conditions.
Chapter Five presents the generalisation of snapshot positioning to non-GNSS satellites.
Chapters Three to Five compose the core of the thesis. To improve readability, each of these chapters follows the same structure: First, it presents the motivation of the work, including the statement of the problem to solve. Then, the chapter presents some background on the research subject, including the related work in the state-of-the-art and the identification of the gaps the thesis is trying to address. The following sections of the chapter present the actual work performed, starting with the hypotheses and theoretical frameworks used, followed by the theoretical analyses and experimental results with real or simulated data, when pertinent. Each chapter is finalised with the conclusions.
Chapter Six presents the overall conclusions of the thesis and proposes some further work.
Some appendices complement the thesis. Appendix A presents the GNSS authentication user needs and high level requirements analysis. Appendix B details a bit-level description of the NMA end-to-end proposal. Appendix C presents the analysis of NMA MAC and key sizes versus bandwidth allocation. As an epilogue of the thesis, Appendix D merges the two main research areas and presents some snapshot authentication methods.
20
Chapter 2. General Technical Background
2.1. A Brief History of Navigation
Navigation is the science allowing us to go from point A to point B. Satellite navigation means navigating using satellites, and we mainly refer here to artificial satellites. Many satellite navigation applications relate to satellite-based positioning only, that is, the determination of point A. This thesis refers to satellite navigation in a broad sense, including satellite-based positioning. A comprehensive history of navigation since the ancient history until the start of GPS is presented in [1]. [2] (Chapter 1) presents a general overview of radionavigation systems, and [3] (Chapter 1) present the GPS program in its early days.
Much before humankind could overcome the Earth's gravitational well and put satellites in orbit, navigators used other means. First, they had to locate points A and B in a map. The Greeks already new that the Earth was spherical and drew maps of the known world at the time with a remarkable accuracy, as the Ptolomean map of the world known in the Hellenistic era in the II century A.D. The estimation of the Earth's radius by Erathostenes around two centuries B.C. was another substantial achievement. He measured the distance, in camel-days, from two points, and calculated the Earth radius by comparing the inclination of the sun at these two points at noon, being the sun at the zenith for one of them.
After the middle ages, Renaissance arrived allowing significant progress in navigation. Men navigated using celestial bodies in a not-so-different way as modern angle-of-arrival radionavigation techniques. During the day, navigators measured the Sun's elevation angle from the horizon at its highest point, and estimated their latitude from tables, or almanacs, relating the Sun's elevation to a given latitude at different days of the year. At night, navigators in the Northern hemisphere could measure the elevation of the Pole Star, knowing that it is pointing to the north, and its elevation angle corresponds to the
21 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION observer's latitude. Navigators could get some help from tables with the positions or celestial bodies, or ephemerides.
In parallel, scientists like Copernicus, Galileo, Kepler and Newton set the basis for modern astronomy and geodesy: Copernicus reformulated the model of the universe, in which the Sun, and not the Earth, was at its centre, contradicting classical Ptolemaic geocentric astronomy. Galileo developed the modern scientific method based on observation of nature and put it in practice by, among others, improving the telescope, which allowed the detailed observation of planetary motion. Thanks to that, Kepler discovered the three planetary movement's laws, which Newton later generalised to the single law of universal gravitation.
While latitude was relatively easy to determine, it took several centuries to compute longitude with a reasonable accuracy to navigate. This goal was not achieved until the 1770s when John Harrison set the basis of modern timekeeping with sea watches H4 and H5, shown in Figure 1. H5 proved accurate to within one second in three days (or 3.8 ppm). This allowed the comparison of observations of the celestial sphere at different positions at the very same time, and hence the longitude.
Figure 1 – John Harrison's portable Chronometer H51 Navigation based on celestial objects, increasingly accurate compasses, and dead reckoning systems was dominant until radio frequency waves arrived. Early radionavigation systems in the XXth century measured the direction/angle of radio waves and the Doppler effect. Following the developments of information theory, electronics
1 Racklever under CC2.5
22
and computing engineering in the first half of the XXth century, several radionavigation terrestrial systems were developed, as OMEGA, LORAN, VOR (VHF Omni-directional Radio Range) or DMEs (Distance Measuring Equipment), some of which are in use today. The first satellite systems developed specifically for radionavigation were:
TRANSIT, a Doppler rate-based radionavigation system developed by the US Navy and operational from the early 1960's composed by 5 or more satellites in a low polar orbit, and which required about one hour to provide a position fix. It included several frequencies to correct for different ionospheric delays. TSIKADA was a similar system developed by Russia. 621B and TIMATION were satellite systems developed by the US Air Force and the US Navy, respectively, which tested on space some key technologies for satellite navigation: highly accurate clocks (TIMATION) for synchronisation, and pseudo-random codes (621B), for better resistance to interference and higher accuracy synchronisation accuracy.
The US Air Force incorporated elements from these systems and developed a system based on a global constellation of nominally 24 satellites with accurate on-board clocks, spread-spectrum signals with pseudorandom codes and multiple carrier frequencies. They called it the NAVSTAR Global Positioning System, or GPS.
Other regions have followed the U.S. in developing their own global navigation satellite system, or GNSS: Russia has developed GLONASS, currently operational, China is developing Beidou, and Europe is developing Galileo. This global effort is complemented by other regional systems as India's IRNSS or Japan's QZSS, and augmentation systems mainly (but not only) for aviation use, as WAAS (U.S.), EGNOS (Europe), MSAS (Japan), or SDCM (Russia), all included in the category of SBAS (Satellite Based Augmentation Systems).
Current ground-based navigation systems and technologies include GBAS (Ground Based Augmentation Systems), VOR/DME/TACAN, or e-Loran. The U.S. is also developing a program called APNT (Alternative Position, Navigation and Timing) to increase resilience of radionavigation.
23 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
2.2. Radionavigation Methods
There are several methods to compute a position based on radio waves. They are briefly explained here:
Time Of Arrival (TOA) implies computing the travel time of a signal from a transmitter at a known position, and the distance, assuming that the signal travels at the speed of light. Performing these measurements for signals from several transmitters, whose position at the time of transmission is known, allows solving all the user position unknowns. These unknowns usually include the receiver clock bias, which is common to all measurements. Time Difference Of Arrival (TDOA) implies computing the receiver position by calculating the time interval between the arrivals of two signals transmitted at the same time from two stations. One of the stations is used as a reference for the other stations. Each TDOA equation of the system can be represented by a hyperbola, and TDOA is also known as hyperbolic positioning. Angle Of Arrival (AOA) implies measuring the angle in which a signal arrives (usually with several antennas). AOA is described in detail in [4] (Ch. 8). Doppler-rate positioning (or Doppler positioning) consists of measuring the signal frequency variation due to the relative speed of the transmitter and the receiver. Doppler-rate positioning principles are explained in [2] (Ch. 1). Instantaneous Doppler positioning consists of measuring the signal frequency Doppler and comparing them with the Doppler estimate at a given time, for several signals. The receiver may need to add an extra measurement to solve the frequency drift unknown. This method is explained in detail in [5] (Ch. 8). Receiver Signal Strength (RSS) positioning is based on matching a position to a previously measured map of positions to signal-strength values.
TDOA and AOA methods are commonly used for mobile localisation. TOA is used for GNSS. Doppler-rate positioning was used for TRANSIT and TSIKADA, and instantaneous Doppler positioning can be used for Assisted GPS to estimate an initial position, later corrected by TOA methods. RSS is commonly used for short-range location systems as Wi-Fi, and usually in indoor environments.
Radionavigation is usually combined with other location sources and sensors as INS (Inertial Navigation Systems) carrying accelerometers and gyroscopes, including MEMS
24
(Micro-Electro-Mechanical Systems) embedded currently in smartphones, odometers, compasses, or GIS (Geographic Information Systems). Modern location services used in mobile phones generally use a combination of the available methods, including GPS/GNSS and other signals.
Figure 2 –LEO, MEO and GEO satellite orbital radiuses, periods and speeds2 2.2.1. Satellite Navigation Systems and Signals
Satellite navigation signals and constellations have some common features that make them suitable for navigation. They use Medium Earth Orbit (MEO) satellites, which are supposed to provide the best coverage and performance versus the cost of placing the satellite constellation into orbit (see Chapter 1 of [6] for more details about GNSS and in particular Walker constellations). Lower altitude constellations would require more satellites to cover the globe, and higher altitude constellations would require more power in the satellites to transmit the same power on ground, and a higher cost to put the satellites in orbit. GNSS use almost circular medium earth orbits of around 20.000- 25.000 Km above Earth surface, with between 3 to 6 nominal orbital planes, for a total of around 24-30 satellites. This seems to be an optimal combination to provide enough coverage of at least four satellites (to solve for a 3-D position plus clock bias) worldwide. Figure 2 shows the orbits of GPS, GLONASS, Galileo and Beidou (COMPASS) together
2 Cmglee under CC BY-SA 3.0
25 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION with the orbits of other LEO (Low Earth Orbit) and GEO (Geostationary Earth Orbit) satellites.
Navigation satellites have ultra-stable atomic clocks. This allows them to provide ranging signals very well synchronised to a common time reference. It also allows the ground segment to better estimate satellite clock offsets and tell the users through the navigation signal.
Thanks to using several constellations, receivers can see nowadays many more than four satellites in view, if they have a multi-GNSS receiver, even in environments with reduced visibility. Figure 3 shows the number of GNSS satellites visible in Aalborg on June 23rd 2015, 12:00 CET.
Figure 3 – Satellites in view foreseen at Aalborg, 23/6/2015, 12:00 (CET)3 Navigation satellite signals use spread spectrum techniques; thus, the signals become more resilient to CW (Continuous Waveform) interference. The spread spectrum technique broadens the bandwidth of the signal, making the ranging signals also more accurate [7]. They also use CDMA (Code Division Multiple Access) techniques to access the media, except for the case of some GLONASS FDMA (Frequency Division Multiple Access) signals. Signals are mainly transmitted in the L band between around 1150 MHz and 1610 MHz. They are transmitted in several frequencies: in addition to offering more services and data, this allows users to correct the ionospheric propagation delays. When received on Earth, the signals are below the noise level: signal power is around -125 to -130 dBm, while noise power is around −110 dBm. The receivers need to
3 GNSS Planning Online [6]
26
correlate the signals with the spreading code replica to increase their power sufficiently to extract the signal information.
The most popular signal modulations in GNSS are BPSK (Binary Phase Shift Keying) and BOC (Binary Offset Carrier) [8]. Figure 4 [9] shows all satellite signal modulations. More details on GNSS signal modulations are provided in [10]. A detailed signal specification of GPS and Galileo can be found in [11] and [12], respectively.
Figure 4 – GNSS signals
27 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
2.2.2. Satellite Navigation Receivers
Satellite navigation receivers are mainly composed of:
An antenna, in charge of transforming the radiated electromagnetic signals into a voltage. Sometimes the antenna is considered a separate part from the receiver. A Front-End (FE), in charge of synthesizing and down-converting the signals (generally received at a too high frequency to be optimally treated) and digitizing them into a binary bit stream. A "baseband processing" component, in which the digital signals are treated to extract the relevant reference parameters: time of arrival (code phase), carrier phase, frequency and data. Usual baseband processing engines are composed of: o An acquisition engine, in charge of searching for the signals at different code delays and frequencies. o A tracking engine, in charge of tracking the signals through delay locked loops and frequency and/or phase locked loops. An application processing block, in charge of generating a PVT (Position, Velocity and Time) solution, allowing receiver positioning and navigation.
Figure 5 presents the main receiver building blocks. An extensive description of classic receiver architectures can be found in Ch. 8 of [3] (Vol. 1). A detailed description of a GPS/Galileo receiver, including Matlab code, is found in [13].
Figure 5 – GNSS receiver blocks Most modern receivers can be aided by an assistance channel. This allows improving Time To First Fix (TTFF) and increasing sensitivity by searching for the signals more quickly and dwelling for a longer time at a given delay-frequency bin during acquisition, receiving more signal energy. More details about Assisted GNSS (A-GNSS) and Assisted GPS (A-GPS) can be found in [5]. Snapshot architectures, further presented in chapters 4 and 5 of this thesis, do not consider the tracking engine and calculate a position based only on the acquisition block.
28
2.3. A Brief History of Cryptography
Cryptography is the science of designing cypher systems. A cypher system protects confidential information from being read by unauthorised people. We call this confidentiality. Cryptography has also other uses, which are data integrity, authentication, and non-repudiation:
Data integrity ensures that the information received is the same as that sent by the sender. Authentication ensures that the source of the information is authentic, that is, the sender is who is supposed to be. This is normally referred to data origin authentication. Authentication also refers to ensuring that an entity is who says he is. In other words, it ensures that information is coming from someone, and corroborates that this someone is who says he is. Non-repudiation prevents that an originator of information denies being the source of that information.
Confidentiality is normally achieved through encryption, i.e. cyphering the message, or plaintext, with a secret key shared between the sender and the receiver. Encryption does not guarantee authentication, as any unauthorised person can send a message to the receiver. When the receiver decrypts the message, it may realise it makes no sense, but it cannot confirm its origin.
Cryptography is complemented by cryptanalysis, which is the process of deciphering encrypted messages without having the key. Cryptology is considered as the ensemble of cryptography and cryptanalysis. Basic definitions and notions of cryptography can be found in [14]. Engineering guidelines for the design or cypher systems can be found in [15]. [16] provides a very good introduction to cryptography, including many examples through history.
There are records that prove that cryptography has been used since the ancient times by most civilisations, mainly by governments and military, but also for private users who dealt with confidential information. Here are some examples of popular documented cyphers used throughout history [14]:
The Caesar cypher, used by the Julius Caesar's Roman Empire. It consisted of replacing the alphabet letters by those X places ahead in the alphabet. For
29 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
example, if X equals 3, A would be replaced by D, B by E, etc. This is a particularisation of substitution cyphers, where, each letter is replaced by another one following a given table. A vulnerability of this cypher (among many others) is that, if the cyphered text is long enough, an attacker can perform statistics on the frequencies of the letters, and guess the conversion table. To protect against frequency analysis, the Vigenère cypher, published in the XVIth century, performed different shifts in the letters, according to a given word or text. For example, if the word 'men' is used, the first letter of the plaintext, or text to be encoded, would shift 12 places (for 'm'), the second one would shift 4 places (for 'e'), the third 13 places (for 'n'), the fourth 12 places, and so on. The Enigma cypher system (Figure 6, right), used to encrypt and decrypt radio communications of the German army during World War II. Enigma machines used three or four interconnected wheels, or rotors, with the alphabet letters scrambled, and a plug-board to swap pairs of letters. To make the cypher more robust, the scrambles turned every time a letter was encoded [16].
Figure 6 – Symmetric systems: diagram (left4) and Enigma machine with four rotors (right) The above cyphers are similar in the following ways:
They require a key: in the Caesar case, the key is the number of places 'X'. In the case of the Vigenere example, the key would be the word 'men'. In case of the Enigma, the key would be the position of the wheels and the letter swaps. Both the sender and the receiver need to know the key to communicate.
4 Source: Microsoft.
30
The key is secret: Once the key is compromised, the whole system is compromised, until a new key is used.
Cyphers using shared secret keys are called symmetric, and generally require a strong effort in key management (generation, distribution, storage, use, change, destruction). For example, during World War II, each day the Germans placed the wheels and swaps in different positions (i.e. changed the key). Finding the key of one day would not help deciphering the messages of the next day. Figure 6 shows a diagram of symmetric systems.
2.3.1. Modern Cryptography and Asymmetric Algorithms
Modern cryptography has been intimately related to the development of computers, since the breaking of the Enigma keys in World War II to our days. Modern symmetric cyphers usually digitalise the plaintext and XOR it with an also digital keystream sequence generated from the secret key. A key of n bits can easily produce a keystream of (2n-1) bits [14].
The plaintext can be XORed with the keystream sequence bit by bit, as is the case of stream cyphers, or in blocks of some bits, as in the case of block cyphers. The most widespread symmetric cypher used nowadays is the AES (Advanced Encryption Standard), proposed by NIST (National Institute of Standards and Technology) in 2001. NIST adopted the algorithm Rijndael, designed by J. Daemen and V. Rijmen [17]. It is a block cypher that encrypts the plaintext in blocks using keys of 128, 192 or 256 bits. It replaced the DES (Data Encryption Standard), published in 1976.
Cryptographic security of cypher systems is commonly measured in security bits. For example, a system of a 128-bit security level implies that there are 2128 possibilities for the key, so an attacker would need to try for a long time before having a minimal probability of success. Well-designed symmetric systems using keys of 128 bits provide a 128-bit security level. Currently, 128 bits of security are considered sufficient for cyphers to be secure for the next decades.
One of the problems of symmetric cryptography is that it requires the sender and the receiver to share a secret key. To avoid this problem, asymmetric cryptography was developed and perfected since the 70s to our days [16]. Asymmetric cryptography is
31 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION based on key pairs where one key is public, and the other is private. This can facilitate information exchange in the following way:
For confidentiality: if Alice wants to transmit a confidential message to Bob, it uses Bob's public key to encrypt the message. Only Bob, who has the private key, can decrypt the message. For authentication: if Alice wants to ensure the authenticity of the message, it adds a digital signature to its plaintext with its own private key. Bob can use Alice's public key to ensure that the message comes from Alice, as only she has the private key.
Figure 7 – Asymmetric Cryptography for Confidentiality (left) and Authentication (right)5 The first publication on asymmetric systems was made in 1976 by W. Diffie and Helleman [18], although the problem was similarly solved by the British Government Communication Head Quarters (GCHQ), but its solution remained secret [16]. Since then, several asymmetric algorithms as RSA (Rivest, Shamir and Adleman), DSA (Digital Signature Algorithm) or ECDSA (Elliptic Curve Digital Signature Algorithm) have been developed. Figure 7 shows diagrams of how asymmetric cryptography is used for confidentiality and authentication.
Asymmetric algorithms are generally based on one-way functions, i.e. functions that are very easy to perform in one way, but almost computationally impossible in the inverse way. For example, the difficulty of factoring two prime numbers p and q of a number n made public in the case of RSA, or the difficulty of calculating the inverse of a discrete
5 Source: Microsoft.
32
logarithm over integer numbers in case of DSA. More details about these and many other cryptographic functions can be found in [19].
2.3.2. GNSS and Cryptography
GNSS are one-way, one-to-many systems. This means that GNSS authentication cannot use challenge-response protocols through a secured two-way communication is established as, for example, when we authenticate ourselves with a token to enter into our bank's secure website to make a transaction. GNSS can however encrypt their signals through symmetric cryptography and digitally sign them through asymmetric cryptography. Here is how the abovementioned four uses of cryptography (confidentiality, integrity, authentication, and non-repudiation), relate to GNSS.
2.3.2.1 Confidentiality
Cyphers have been intimately related to satellite navigation since its inception, but mainly for military purposes. The widespread GPS C/A 1-millisecond spreading codes were transmitted in-the-clear (i.e. unencrypted) to allow military users to perform a fast signal acquisition and time synchronisation, before switching to 7-week portion of a much longer Y code, encrypted before transmission, and once encrypted known as P(Y) code.
Other governmental signals as Galileo's PRS (Public Regulated Service) or GLONASS or Beidou military signals are also encrypted. Galileo transmits also the CS signals that can be encrypted for civil purposes.
One purpose of signal encryption is access control, i.e. confidentiality. Some years ago, the GPS applied an intentional degradation to the open signals called Selective Availability, and only receivers having the secret keys could access the more accurate signals. In addition, in crisis situations, jamming the open signals can deny navigation services to users not having the secret keys.
Another property of GNSS signals to avoid eavesdropping is that, as said before, they are received at a very low power on earth. In order to decode the data modulated in the signals, and due to the DSSS technique in which GNSS signals are modulated, the receiver needs to have the pseudo random code replicas to correlate the signal. In the absence of the codes, the signals cannot be acquired. Therefore, only the users having the spreading codes (or a high gain directive antenna, which is cumbersome and expensive)
33 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION can de-spread the signal and raise it above the noise level and get the reference parameters from the satellites (time of arrival, frequency, phase and data). This implies some sort of steganographic protection, similar to writing in 'invisible ink'.
2.3.2.2 Data Integrity
While cyphers can guarantee data integrity, the integrity of the data transmitted by GNSS systems is guaranteed by the data encoding, and usually by a CRC.
2.3.2.3 Authentication
Authentication is generally provided through Message Authentication Codes (MACs) or digital signatures. MACs rely on symmetric schemes and are based on generating a tag that depends on the message to protect and the secret key. The receiver then re-generates the MAC with the received message and its own key, and both should coincide. Digital signatures are based on public-private key schemes, as explained before.
In the case of GNSS, authentication is needed to protect users against malicious attacks whereby spoofers falsify GNSS signals making them believe they are somewhere else. It is also necessary to avoid self-spoofing of malicious users reporting a falsified position.
GNSS signal authentication can relate to the two main components of the signal: the spreading codes and the data.
If spreading codes are encrypted (as in the P(Y) case), only users having the key can acquire the signals. Therefore, signal encryption in this case provides some level of authentication. This was also one of the uses of the encrypted codes by the GPS P(Y) military users. Receivers contained a SAASM (Selective Availability and Anti Spoofing Module) to authenticate the codes, and therefore the time of arrival, against spoofing attacks. So, GNSS authentication, although relatively new in the civil domain, has been used in the military domain since the beginning of GPS.
Signal encryption per se does not provide authentication though. For example, an attacker would have difficulties to modify the data modulated over encrypted spreading codes, but this does not mean that the attack is impossible. Some methods in the GNSS literature, as [20] [21], have been proposed to authenticate spreading codes for public users. They are based on the insertion of some cryptographic information that can be
34
verified but does not prevent receiving most of the spreading code, and therefore acquiring and tracking the signal.
GNSS authentication requires also the authentication of the data. This is often called Navigation Message authentication, or NMA [22]. Authentication of the data for public non-controlled user communities can be performed by digital signatures [23], so receivers can authenticate the data just by having a public key. Authentication can also follow hybrid (symmetric/asymmetric) approaches relying on time-delayed asymmetry, as is the case in this thesis.
2.3.2.4 Non-repudiation
Non-repudiation seems not useful for GNSS if interpreted as avoiding that a satellite or system denies being the source of the signals, as this is not expected to happen. It can be however useful for avoiding that a user denies he was at a given place at a given time. This use may be relevant for GNSS location applications with financial or legal implications, as e.g. road tolling.
35 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Chapter 3. Navigation Message Authentication
3.1. Motivation
Over the last decade, the increasing dependence of civil applications on GPS has raised concerns over GPS security [24]. Gradually, some demand for authentication services has arisen in the location community. Due to the high demand to strengthen GNSS civil signals for consumer or mass market users, the GNSS research community is studying how positioning authentication could be implemented based on GNSS signals and other sensors. The work presented in this chapter is the partly result of an internal action within the Galileo program whose purpose was to study how Galileo could authenticate its signals with minimal modifications to the system baseline, and before its Full Operational Capability. The Galileo signal design and message structure is adequate for introducing authentication, as it allows higher bitrates compared to other GNSS [12, 11]. In addition, due to the Galileo safety-of-life service 're-profiling', a significant amount of bandwidth has been liberated for future uses.
Previous literature suggests that, when complemented with additional checks at the receiver, NMA can provide a reasonable level of protection not only of the satellite data but also against replay attacks [25, 23]. In any case, as the Galileo service offering includes spreading-code encrypted civil signals in the E6-B/C as part of the Commercial Service [26], an NMA service could be combined with these signals for users that rely on encrypted spreading codes, as described in [27]. The proposed NMA scheme could also be upgraded to spreading code techniques, such as [20] or [28], in future Galileo generations. . In parallel to the analysis of this proposal, the Galileo program has carried out other authentication testing activities, some of which have included some signal-in- space testing in the Galileo E6 band. They are reported in [27] and [29].
As described in the literature, NMA required four digital signatures, or for MAC-key pairs, for a 4-satellite data-authenticated PVT. This implies receiving many additional
36
bits from each satellite. The main scientific and engineering challenge of this research area has consisted in designing and characterizing a service that decreases the amount of bits required and can work for all kinds of users, while being robust against cryptographic and signal attacks. The work in this thesis proposes an authentication solution for Galileo E1B I/NAV message implementable for the Galileo first generation. The solution can provide data authentication and anti-replay protection based on the authentication of unpredictable symbols.
One of the main drivers for the authentication solution proposed in this thesis is the minimisation of modifications of the Galileo infrastructure with respect to the current baseline (based on the available documentation). For this reason, the authentication solution proposed is based on NMA as opposed to the authentication or encryption of the signal spreading codes. For this reason also, it is based on the "Reserved 1" field of the I/NAV message and relies only on satellites connected in real time to the ground segment. Other authentication solutions not subject to these constraints and based on modifications to the satellite and ground segments may yield even better performance.
The sections in this chapter present first some background on information security and GNSS authentication. Then, the user needs, or high level requirements used for the NMA design are presented. The following section presents a performance framework to characterise NMA (and GNSS authentication in general). Then, the concept proposed is presented, followed by a detailed implementation proposal for Galileo I/NAV and the experimentation results.
3.2. Background
To understand the purpose of the authentication solutions proposed later, it is important to explain what we are trying to protect, and against what. This section presents some background on information security systems, security risk assessments and presents some threats and mitigation actions to GNSS positioning, NMA being one of them.
3.2.1. Information Security Management Systems (ISMS)
Security cannot be guaranteed by cryptography only. It depends on the security of the whole system. The background used for protecting systems providing any information (like GNSS, or GNSS receivers) is based on ISMS standards and policies. ISMS provide a generic framework to analyse and manage the security of information, including how to control information and react in case of threats. ISMS deal with cryptography and other
37 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION broader security aspects as physical security, communications, operations, procurement/acquisition, operations or human resource management. Most ISMS identify confidentiality, integrity and availability as the critical factors:
Confidentiality is understood as the protection of the information from unauthorized parties (similarly to the previous definition in Chapter 2). Integrity is understood as the protection of information from modification by unauthorized users (also similarly to the previous definition). Availability is understood as making the information available to authorized users.
Cybersecurity, or IT security, refers to information security for computers and computer networks. Cybersecurity is fully applicable to a GNSS receiver, being it a computer providing information based on some RF hardware.
3.2.2. Standards
The ISO/IEC 27000 series from ISO (International Standards Organisation) and IEC (International Electrotechnical Commission) on security of information systems [30] are now the main international security standards. Current ISMS standards are derived from BSI (British Standards Institution) BS 7799, published in the 90's, which established best practices for Information Securities. This was later incorporated in to ISO standards, that in the 2000s became part of the ISO 27k series, which merged information security management practices with other ISO generic standards for quality management.
The "Common Criteria for Information Technology Security Evaluation", commonly referred as "common criteria" ISO/IEC 15408 [31], provide a framework to specify security requirements to develop, analyse and test computer-based software. The Common Criteria ensures that the specification, development and testing of a product has been conducted according to a standard and in a repeatable manner according to a certain "Protection Profile", which can be certified. The CC is not so relevant for this thesis, as the analysed threats focus on signal aspects, as opposed to cybersecurity aspects. We assume cybersecurity requirements for NMA implementation as similar as to other existing IT devices so this falls outside the main scope of the thesis.
In addition to ISO standards, other organisations as U.S. NIST (National Institute for Standards and Technology) develop standards for cybersecurity, as is the case of the AES
38
[17] and many other referred to in this thesis. Other national security standards include EBIOS [32], the French government security standard, or CRAMM (CCTA (Central Computing and Telecommunications Agency) Risk Analysis and Management Method) [33].
ISO/IEC 27005, "Information technology — Security techniques — Information security risk management" is the standard for risk management of the 27k series. The standard follows a common definition of a risk as “a combination of the consequences that would follow from the occurrence of an unwanted event and the likelihood of the occurrence of the event”. The methodology is based on the following steps to identify:
Assets at risk, and therefore to be protected. Threats to these assets. Vulnerabilities of the assets to the threats. Impact if the threats are materialised. Mitigation actions.
The methodology just provides a framework. It does not provide the knowledge of which are the threats and the technology required for them. A very preliminary security risk analysis of GNSS positioning, from the receiver point of view, implies to define:
Assets: the main asset at risk is the position and time solution generated by the receiver. Threats: they are presented in the next section. Vulnerabilities: from a receiver perspective, one could relate them to the main receiver blocks: Antenna, RFFE (Radio Frequency Front End), ADC (Analog to Digital Converter), signal acquisition, signal tracking (unless a snapshot approach is followed), PVT, and communication with a third party, if applies. Other conceptual approaches are possible. The focus of this work is on vulnerabilities at the level of signal reception, or antenna level, i.e. how can an attacker attack what the receiver is receiving. In a broad sense, cybersecurity attacks to the receiver must also be considered. Impact can be assessed per threat and per receiver stage (vulnerability), i.e. how each attack could affect ADC, acquisition, tracking, etc. Mitigation Actions: they are presented in the section 3.2.4.
39 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
3.2.3. GNSS Positioning Threats
Jamming, spoofing, and meaconing are in most of the GNSS literature the principal classification of threats to GNSS signals [34] [35]. The Volpe Report [24] follows a risk analysis similar to the abovementioned, and concludes that GPS is a critical infrastructure subject to interference and should be backed up by other radionavigation aids. It also recommends the application users to assess the risk of losing GPS. More concretely, as regards the GPS threats, it classifies them in unintentional and intentional disruptions. Recent GNSS literature also maintains the same classification [23] [25]. In particular, a survey of spoofing attacks has been presented in [36] not long ago.
The preliminary threat model proposed here divides the attacks into signal attacks and non-signal attacks. Signal attacks affect the reception of GNSS signals. Non-signal attacks affect the receiver device or to the key management infrastructure. Here is a generic definition of jamming, meaconing and spoofing signal attacks:
Jamming refers to the transmission of an interfering signal (e.g. pulsed, continuous) in the bands used by the GNSS signals. It cannot be counterfeited by the signal design (other than raising the transmission power) and leads to a service denial (i.e. no GNSS PVT), as opposed to a wrong GNSS PVT. Some authors propose smart jamming as an intermediate attack between jamming and spoofing [37]. Smart jamming is jamming using GNSS-like signals, for example with GNSS PRN (Pseudo Random Number) codes, which may affect the tracking loops leading to false (but incoherent) PVTs. Meaconing is generally defined as the replay of the full GNSS digital stream. This type of attack affects any kind of GNSS signal authentication scheme, with the limitation that it can only delay the whole signal stream, therefore falsifying the receiver clock bias at the position of the antenna used for meaconing. Selective meaconing attacks using directional high-gain antennas may lead to a false position. Spoofing can be defined as one of these two: The transmission of fully simulated signals without any replication capability of the authentic signals: this seems the easiest attack to which current open signals as GPS L1 C/A are vulnerable. NMA fully protects from this attack. The reception of the actual signal and its rebroadcast with a minimal delay. This is known in some literature [23] as a Security Code Estimation and
40
Replay (SCER) attack. NMA, can protect from these attacks but a probabilistic analysis using hypothesis testing methods is required.
Non-signal attacks can be divided in:
Tampering within the receiver to alter the stored bits from the demodulated signal, the result of the authentication check, or the previously stored public keys. Provision of the wrong keys to the receiver by attacking the Public Key Infrastructure (PKI). Alteration of the position reported by the receiver to a third party.
Taking the above into account, GNSS authentication should:
Counterfeit any type of spoofing attacks through fully simulated signals. In case of a SCER attack: o Confirm the authenticity and integrity of the data used for the authenticated PVT. o Confirm, up to a certain probability and under certain conditions, the authenticity of the signal timing used to generate the time-of-arrival measurements used for the PVT calculation.
3.2.4. Detection and Mitigation Actions
For unintentional disruption, the recommendations from [24] to GPS are to transmit at a higher broadcast power, and to use of several civil frequencies. Against intentional disruption, it recommends to:
Transpose military anti-jam techniques to civil technologies; Develop anti-spoofing techniques in the receivers. Monitor the evolution of threats to take appropriate countermeasures.
In particular, the following techniques are recommended against spoofing in the receivers:
Amplitude Discrimination Time-Of-Arrival Discrimination Consistency of Navigation IMU Cross-Check Angle-Of-Arrival Discrimination
41 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Cryptographic Authentication (the main subject of this chapter).
Redundancy within measurements through RAIM (Receiver Autonomous Integrity Monitoring) and with other non-GNSS systems is recommended. This recommendation has been materialised in US's APNT (Alternative Positioning, Navigation and Timing) program. Complementarily, L. Scott in [20] also proposes receiver countermeasures, divided in those at signal level and those at navigation level. At signal level, these are proposed:
Use J/N (Jamming to Noise) meter to check for above normal energy levels
C/N0 (Carrier to Noise density ratio) monitoring
C/N0 and J/N verification Multi-antenna phase difference measurement. "deep acquisition" for weak, real signals.
At navigation level, the proposed mitigation actions are:
Signal synchronisation ("watch time" vs "signal time" comparison). continuity of position and timing. consistency with sensors. residual verification (e.g. RAIM-like and FDE).
[36], [28] and [23] also propose the addition of trusted clocks as an additional protection against spoofing attacks, and this technique is also detailed in Appendix D. Appendix D also proposes the use of geometrical constraints or consistency with digital maps.
3.2.5. Detection and Mitigation based on GNSS Signal Properties
Currently, there are no civil authentication measures or services as such in civil GNSS signals. However, since the Volpe report in 2001 [24], there has been public research in the subject. We divide them in those at spreading-code level and those at data level.
Reference [20] mentions data message authentication (known as NMA in this thesis), SCA (Spreading Code Authentication) and SCE (Spreading Code Encryption). It also refers to Spread Spectrum Security Codes (SSSC), similar to spreading code watermarking techniques as proposed in other references as [38]. Reference [22] coined the term NMA and proposed several NMA techniques, including one based on TESLA, although using different keys from different satellites and requiring about 238
42
authentication bits per satellite. It also proposes also NME (navigation message encryption). Many publications from the research group from the University of Texas at Austin present the results of actual spoofing attacks and GNSS and receiver authentication methods [39] [40] [25] [41]. On NMA in particular, [23] proposes 466-bit digital signatures over GPS CNAV message and their integration in anti-replay protection measures, and [40] proposes a hybrid ECDSA-TESLA approach optimised for GPS CNAV. Also, Stanford GPS laboratory group have presented an amount of solutions for radionavigation authentication [35] [42] [43], including some TESLA-based protocols for e-Loran authentication [44] or GBAS/SBAS [42], both studying TESLA. The next sections provide further references to the state of the art, when adequate.
3.2.6. Summary
Here are some conclusions from the background literature review:
Any measures for securing radionavigation services can and should be analysed through standard Information Security Management Systems (ISMS) and Security Risk Assessment standards. In particular, ISO 27000 series provides guidelines for all kinds of analysis. Concerning security risk assessments, other similar methodologies apply at national level (e.g. EBIOS or CRAMM). As regards cryptographic security, NIST standards are one of the main references. Security Risk Assessments usually consist of a framework to identify the assets under risk, the threats, the vulnerabilities, the impact and the mitigation actions. GNSS threats are generally divided in jamming, spoofing and meaconing. GNSS authentication literature presents a wealth of GNSS threat detection and protection based on radionavigation backups, receiver measures, GNSS authentication and policy or security management-related actions. No GNSS authentication (be it NMA or SCE) is fully robust against all threats. However, they can be robust against most threats and be complemented with other measures at the receiver or by other aids. Signal unpredictability obtained by SCE or NMA, is beneficial to protect against replay attacks.
3.3. User Needs, High Level Requirements and Design Drivers
The design of an NMA service needs to take into account target users environments, receiver technological constraints, robustness and performance. In addition, feasibility in the system and backward compatibility with the current signals has been taken into
43 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION account as well. The user needs and high level requirements identified are summarised in Table 1. Some background to the table is presented in Appendix A.
Table 1 – Summary of User Needs and High Level Requirements
Target Users and Receiver Constraints
The solution shall work in standalone mode
The solution shall work in assisted mode
Security-related receiver requirements shall be minimised
The solution must be E1 mono-frequency
The solution shall not require any additional hardware components than those of a standard low-cost receiver
The solution shall be computationally feasible in a standard low-cost receiver
Robustness and Performance
The solution shall use standardised functions and protocols considered secure by the cryptographic community
The solution shall be cryptographically secure in the long term
The satellite and receiver key update frequency must be minimised
The solution robustness against attacks shall be at least comparable to other solutions in the state-of-the-art
The solution performance shall at least be comparable to other authentication proposals in the state-of-the-art
Feasibility
The solution shall be compatible with current Galileo satellites
The solution shall be compatible with Galileo uplink capabilities
The solution shall be compatible with the Galileo ground segment
The solution shall be compatible with the Galileo operations concept
Backward Compatibility
The solution shall be compatible with the current Galileo signal specification
The solution shall not degrade the Galileo navigation data transmission performance
The solution shall not prevent other signal evolutions.
44
An NMA service can provide two service levels: data authentication and signal unpredictability for protecting against replay attacks. Based on the abovementioned user needs and types, the authentication design drivers, as regards data authentication, are:
An asymmetric scheme is favoured, so the users do not need to store, protect and replace a secret key. Publication of keys through a public web or a dedicated public key infrastructure (PKI) is therefore needed to certify the authenticity of the signal in space data. The authentication of the data should not degrade user accuracy, or this degradation, if any, should be minimised. The use of only authenticated satellites versus the use of all satellites should not lead to a lower availability. In other words, all satellites visible by the user shall be authenticated (either through the SIS, or through receiver verifications). Availability is actually one of the drivers for the NMA design due to the following: o Not all satellite signals may be authenticated by the GNSS. o Not all satellite signals may be authenticated if the user does not successfully demodulate the authentication data due to shadowing or multipath. The solutions shall be cryptographically secure.
As regards anti-replay measures:
The signal shall contain unpredictability features. The design must reduce latency between the start of authentication information transmission, and its verification by the user. It shall minimise the amount of information required for the verification authentication, without compromising security.
Other design drivers related to the usability of authentication at start-up are:
For standalone users, Time To First Authenticated Fix (TTFAF) shall be minimised. Signal unpredictability provided often could help assisted users having authentic data from their assistance server (and potentially a trusted time reference), by verifying that their measurements are not replayed.
45 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
3.4. Performance Indicators
Ideally, user authentication needs could be summarised as having a fully guaranteed positioning and timing service without any degradation in accuracy, availability and time to first fix in any environment. On this premise, the main four user performance drivers considered are availability, accuracy, TTFAF, and robustness. The thesis proposes other lower-level performance indicators, which relate to these four as depicted in Figure 8. Further details can be found in [45].
The proposed KPIs (Key Performance Indicators) apply differently whether they are used to characterise data authentication only, or anti-replay. Given that anti-replay capabilities depend partly on the receiver, the higher-level indicators are defined for data- authentication only, unless otherwise stated. For example, for data authentication, all data-authenticated satellites can be considered in the PVT solution accuracy and availability performance, although some may not be protected against replay. They can be translated between data authentication and anti-replay easily, just by relating them to data-authenticated satellites or data-authenticated and replay-protected satellites. In addition, some indicators as MPT (Maximum Predictable Time) and USR (Unpredictable Symbol Ratio) only apply to the anti-replay feature.
Figure 8 - Authentication Performance Framework Accuracy reflects the user position error using only data-authenticated satellites. It is equivalent to standard PVT accuracy and can be approximated as follows [6]:
(3.1) 퐴푐푐푢푟푎푐푦퐴푢푡ℎ[푚] = 푈퐸푅퐸퐴푢푡ℎ [푚] ∙ 퐷푂푃퐴푢푡ℎ
푈퐸푅퐸퐴푢푡ℎ: User Equivalent Range Error represents the accuracy of a ranging measurement from an authenticated satellite. It depends on the accuracy of the orbit,
46
clocks, ionospheric and tropospheric corrections, multipath and receiver noise [2]. Aspects that could increase UERE due to authentication are:
The navigation data authenticated is less than the total navigation data. This may happen if e.g. only the satellite almanacs were authenticated. The age of the authenticated navigation data is higher than the most recent navigation. In the proposed NMA implementations, this effect would be minimal.
퐷푂푃퐴푢푡ℎ: Dillution Of Precision, or more generally, different satellite geometry of the authentication solution, can be due to these factors:
If a user has more difficulties to receive the authentication information than the standard navigation information, then successfully authenticated satellites, even in the absence of attacks, may be less than the total. If the system is not able to authenticate all the satellites in view by the user, for example because the user uses other non-authenticated GNSS, or because the system can only authenticate a subset of its satellites.
Availability reflects the percentage of time, over a certain interval, that a user under certain conditions correctly receives the authentication information for at least four satellites. As is the case for 퐷푂푃퐴푢푡ℎ, it is affected by the reception conditions and number of authenticated satellites. A global worldwide service volume area must a priori be targeted by a GNSS.
Time to First Authenticated Fix reflects the time a receiver takes to calculate a position fix based on at least four data-authenticated satellites.
Robustness encompasses all metrics and indicators related to the security achieved by the authentication solution. Robustness KPIs MPT and USR are described later.
The following paragraphs describe the lower level KPIs that relate to these four as illustrated in Figure 8. Out of these, AER (Authentication Error Rate) and TBA (Time Between Authentications) are highlighted as they stand out as the drivers for authentication.
System Availability represents the percentage of time that the system has at least four data-authenticated satellites above a certain elevation at certain positions over a given area, independently of the user reception conditions.
47 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
System TTFAF represents the time that the system takes to transmit the navigation and authentication data required for a fix with data-authenticated satellites, independently of the user reception conditions.
This section explains more in detail the four indicators considered the most important. They are the Authentication Error Rate (AER), the Time Between Authentications (TBA), the Maximum Predictable Time (MPT) and the Unpredictable Symbol Ratio (USR). AER and TBA are highlighted in the figure due to their high influence on other indicators.
3.4.1. Authentication Error Rate
AER is defined as the probability of error of a satellite being authenticated in the absence of attacks but in the presence of disturbances of a real transmission channel. It is equivalent to packet error rate, the packet encompassing the bits required for a successful authentication. AER is mainly dependent on the Bit Error Rate (BER) and the total Number of Navigation and Authentication bits (NNA) required for a successful verification.
퐴퐸푅 = 1 − (1 − 퐵퐸푅)푁푁퐴 (3.2)
AER depends on the authentication solution, the signal definition and the shadowing or fading effects in the communication channel affecting the bit error rate. BER is understood as the number of bit errors divided by the total number of transferred bits during a time interval, or the percentage or probability of bit errors. For open-sky environments, an Additive White Gaussian Noise (AWGN) channel can be assumed. In this case, assuming no forward error correction, the BER can be derived by
1 퐵퐸푅 = ∙ 푒푟푓푐(√퐶/푁 ∙ 푇) (3.3) 2 0 where erfc is the complementary error function, C/N0 is the carrier to noise ratio, and T is the bit period (e.g. 20 ms in case of GPS L1 C/A data bits). Number of Navigation and Authentication bits required (NNA), includes the Number of Navigation bits (NN) and the Number of Authentication bits (NA) required for a successful verification:
푁푁퐴 = 푁푁 + 푁퐴 (3.4)
48
The minimisation of NA while preserving adequate security strength is one of the main challenges and drivers of the design of a data authentication scheme. Not only it has a high impact in the AER, but it also has a direct impact in the bandwidth overhead required by the GNSS for authentication. This later aspect is not the focus of this paper as due to the re-profiling of the Safety-Of-Life service of Galileo, the current Galileo I/NAV message structure and bitrate allow enough margin to add authentication and keep spare bandwidth for future uses.
3.4.2. Time Between Authentications
Time Between Authentications (TBA) is the time elapsed between two successive authentication verifications of a satellite. This means the time, for a certain satellite, to transmit a new full digital signature, MAC, MAC + key, or whatever authentication information is chosen. This parameter is relevant for the authentication solutions mainly for two reasons:
It influences TTFAF: the receiver needs to wait for all authentication information to be received. It influences robustness: during the time a receiver is processing data for the next authentication verification, it has no way to verify that the incoming signal is authentic. The receiver can navigate with past authenticated data, but if the signals are coherently replayed, the user will be vulnerable until he realises that the next authentication fails. Therefore, after an data-authenticated, TBA is mainly relevant to protect against replay attacks.
Once the navigation and authentication information is received, the time for the receiver to perform the authentication in the order of few milliseconds, and therefore negligible, for symmetric or even asymmetric schemes. It is therefore considered that a KPI such as Authentication Latency, understood as the time between all navigation is received, and it is actually authenticated, is not necessary, and all the relevant aspects are already encompassed in TBA.
TBA is a design parameter so it need not be computed analytically. The staggering or offsetting of the authentication events for different satellites can implemented, as proposed in [23], in which case the user can authenticate subsets of satellites at different times, reducing coasting time. Then, a distinction between 'user' TBA and 'system' (or
49 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION channel) TBA can be made. In this chapter by TBA we refer to 'system' TBA, unless otherwise stated. In real conditions, assuming some AER, average TBA is:
푇퐵퐴 푇퐵퐴̅̅̅̅̅̅ = (3.5) 1 − 퐴퐸푅
TBA and AER drive the Time To First Authenticated Fix (TTFAF). Assuming that the user already has valid (but not yet authenticated) navigation data, or that the receiver receives simultaneously the navigation and authentication data, the average TTFAF is:
푇퐵퐴 푇푇퐹퐴퐹̅̅̅̅̅̅̅̅̅ = + 푇퐵퐴̅̅̅̅̅̅ (3.6) 2
TBA/2 is the mean of a uniform probability distribution between 0 and TBA, and represents the average time that the receiver needs to wait since data demodulation starts until a new authentication starts (assuming that authentication information is transmitted sequentially, i.e. all the information for the next authentication is transmitted after the last authentication). The average TBA takes into account the fact that, because of data demodulation errors, sometimes the first authentication will be erroneous, increasing the TTFAF. Signal acquisition time is left out of the computation formulas, as it does not add value to compare authentication solutions in the context of this work.
3.4.3. Robustness against Replay Indicators: Maximum Predictable Time and Unpredictable Symbol Ratio
MPT reflects the maximum time that, according to the design, the signal is predictable. It is based on the fact that if any of the inputs of the authentication function (e.g. the message to sign or the signature key), varies, the output authentication information will be fully unpredictable. If the authenticated information includes time, the output bits will always be unpredictable. The main purpose of reducing MPT is to constrain attacks taking control of the receiver tracking loops. Having unpredictability in the signal very often may also favour snapshot approaches whereby a signal snapshot containing unpredictable features is captured in the receiver, time-tagged with a trusted clock and checked in a server. MPT is a design parameter and therefore can be computed from the NMA data structure.
USR, in the context of this work, reflects the percentage of unpredictable symbols out of the total number of symbols over a given time period in which the message structure is repeated. With this parameter, if a replay detection test statistic based on hypothesis
50
testing is computed from the estimation of unpredictable symbols (or the first samples thereof), USR gives an indicator of how long a receiver has to wait to have a reliable test statistic. USR is a design parameter and therefore can be computed from the NMA data structure.
3.4.4. Other Robustness Indicators
Symmetric key strength relates to the key length of a symmetric key scheme that would provide the same level of security. This key strength should drive the design of asymmetric schemes for NMA.
Key Exposure Time is also a relevant parameter for a NMA solution design. It can be defined as the time that a public key is known to potential attackers. The exposure time of the public keys to be transmitted through other means that the SIS (Signal-In-Space), and stored in the receiver, needs to be traded off with the autonomy of the authentication solution. Over-The-Air Rekeying (OTAR) can be implemented to reduce exposure time.
3.5. Proposed GNSS Authentication Concept
This section presents the authentication concept on which the proposed NMA proposal relies. It is based on two main principles:
The authentication of data from some satellites by other satellites, or cross- authentication, as described in [45]. The use of different keys from different satellites but from a single one-way chain shared by all satellites, through a Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol [46].
3.5.1. The TESLA Protocol Features
The main properties of the TESLA protocol make it very suitable for radionavigation authentication, in spite of the fact that it is standardised to a lesser degree than some widely used digital signatures. These properties are [46]:
Low computation overhead for the generation, and mainly the validation, of authentication information. Low communication overhead. This is a key parameter, which affects AER and TBA. It is maximised if a single chain is used for several satellites, as in the proposed case.
51 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Strong robustness to data loss, as is the case for GNSS receivers in environments with reduced visibility. Optimal for multicast (one-to-many) transmissions, as is the case for GNSS.
In addition to the obvious requirement that the cryptographic functions used are cryptographically secure, two assumptions are required for TESLA to provide security: Firstly, the receiver is loosely synchronised with the transmitter. With the current proposal, the time uncertainty can be bound by several minutes. Secondly, another authentication system is required at start-up. The receiver is required to have an authentic public key or root key.
TESLA is based on the transmission of a Message Authentication Code (MAC) to authenticate the plaintext message and the delayed transmission of the key used to compute the MAC. This key belongs to a chain generated through a one-way function F.
The chain starts with a random seed key Kn, which is secret, and ends with a root key K0 that is public and certified through external means so the receiver can consider it as authentic.
푛 퐾0 = 퐹 (퐾푛) (3.7) where Fn means recursively applying n times the function F. A hash function is a one- way function, so each element of the chain can be constructed by hashing the previous element, as shown in Figure 9. The diode symbol represents a one-way function.
Figure 9 – TESLA one-way chain of keys GNSS authentication through TESLA would be performed in the following way:
The receiver receives the navigation data and the MAC. The receiver receives later a key from which the MAC can be generated.
52
The receiver authenticates the key with a previous key from the chain that is considered authentic, or the root key, by performing function F the required number of times. The receiver re-generates the MAC with the key and the data, which should coincide with the previously received MAC.
More details about TESLA protocols for GNSS can be found in [42], [22], [47], [48] and [40]. The cryptographic strength of the chain generation mechanism is increased by adding to the hashing process other information known to the receiver, as e.g. a counter or time reference. In addition, the key size can be reduced by truncating the hash output, in order to reduce communication overhead. In this case, the function F is proposed as follows:
퐹(퐾푚, 퐺푆푇푗) = 푡푟푢푛푐(퐾푙푒푛, (ℎ푎푠ℎ(퐾푚 || 퐺푆푇푗))) (3.8)
where Km is the key used as an input to the function, GSTj is the Galileo System Time associated to the beginning of the authentication frame 'j' in which the key is applied, trunc is the truncation function to the Klen Most Significant Bit (MSB), Klen is the length of the key, hash is hash function used (e.g. SHA-256 [14]), and || is the operator to concatenate Km and GSTj into a single bit chain. An authentication frame here refers to the interval of time during which authentication information (MACs and key) are transmitted. The authentication frame finalises with the authentication verification, once the key has been received.
One potential vulnerability to this chain generation process is that, if the start and end times of the chain are known by an attacker, e.g. if the attacker knows that the K-root of each new chain will be tied to Jan 1st 00:00:00 of each new year, the attacker would also know the applicability time of Kn, and could pre-compute several chains much before their K-root is published. To protect against that, two measures are possible: First, the K- root applicability time can be made less deterministic, so the attacker has to search for more options. Second, a few-bit pattern published together with the K-root, and used in function F, would make pre-computation attacks much more difficult. In this second case, the function F would be as follows:
퐹(퐾푚, 퐺푆푇푗, 푝푎푡푡푒푟푛) = 푡푟푢푛푐(퐾푙푒푛, (ℎ푎푠ℎ(퐾푚 || 퐺푆푇푗 || 푝푎푡푡푒푟푛))) (3.9)
53 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
In a standard TESLA approach, each sender (satellite) uses a different one-way chain, as shown in Figure 10. If a receiver authenticates four satellites, it should receive, in addition to the data to authenticate (P1, P2, P3, P4), four MACs (MAC1, MAC2, MAC3, MAC4) and four keys (K1, K2, K3, K4), one from each satellite, where each key belongs to a different chain. The next section presents an optimization whereby all senders (satellites) use the same key chain, in order to reduce AER.
Figure 10 – Standard TESLA approach with a different key and chain per sender 3.5.2. TESLA with a Single Chain from Several Senders
The proposed concept differs from other solutions that have been described in previous literature in the use of a single one-way chain for all senders, as opposed to the use of a single one-way chain for each sender. The main motivation of this choice is to drastically reduce the AER: by allowing all the satellites to be authenticated through the same chain, a user needs to receive only a correct key from any satellite to authenticate all satellites. This reduces dramatically the number of bits required for calculating a PVT using data- authenticated satellites.
A single chain is beneficial not only for the NMA success rate in stationary conditions (i.e. after a certified root key is in possession of the receiver): It also helps during the initialization, thanks to the fact that only one root key is required for all satellites, as opposed to one root key for each satellite. This highly reduces the Time To First Authenticated Fix.
54
Figure 11 – TESLA approach with the same key for all senders The proposed solution is especially useful when one or few satellite signals are received in good conditions, while others are received at lower elevation angles or subject to multipath or blockage and therefore they are demodulated with a much higher bit error rate, which may be the case in urban environments. Even if due to shadowing or fading, no key is successfully demodulated from any satellite in a certain authentication frame, which lasts a number of seconds equivalent to TBA, any key from the next authentication frame can be used to verify the previous authentication frame.
3.5.3. TESLA with a Single Chain and Different Keys from Different Senders
One problem that arises when using a single one-way chain for all satellites is that it reduces signal unpredictability: if the same key is transmitted at the same time from all satellites, it will be received at different times by users due to the different satellite clock offsets and, principally, due to the differences in distance. For example: The signal from a Galileo satellite at the zenith would arrive at the Earth surface after approximately 77 ms, while the signal from a satellite at a very low elevation could take around 100 ms. A spoofer would have some milliseconds to estimate some unpredictable bits from one satellite and replay them with a delay at another one, spoofing the position even if the data message is authentic. As a result, if all satellites are transmitting the same key at the same time, only the symbols from the satellite closest to the zenith can be considered unpredictable.
This problem can be overcome by transmitting different keys from different satellites, but still from the same chain. In this way, the key bits would still be unpredictable while the MAC key is recoverable from any later key of the chain. At a given authentication frame j, the key used for the MACs can be derived from the key received from satellite i as follows:
55 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
푖−1 퐾푗,푀퐴퐶 = 퐹 (퐾푗,푖, 퐺푆푇푗) (3.10) where 퐾푗,푀퐴퐶 is the key used for the MAC computations of the MACs transmitted at j, 푖−1 퐹 is the F function in equation (3.8) applied i-1 times to Kj,i, the key received from satellite i in authentication frame j, and 퐺푆푇푗 is the Galileo System Time at the beginning of authentication frame j. In this case, the key Kj,1 would be transmitted by satellite 1 at authentication frame j and be used for the MAC computation, i.e. Kj,1 = Kj,MAC. To avoid the reuse of the key, another chain element can be added, or an additional function can be used to generate the MAC keys from the transmitted keys as proposed in [42] and [46]. For the sake of simplicity, at the time being this is not part of the NMA proposal in this chapter. This potential evolution does not affect the conclusions derived from the proposal.
To validate the MAC key in authentication frame j with the MAC key from the previous frame j-1:
푆 퐾푗−1,푀퐴퐶 = 퐹 (퐾푗,푀퐴퐶, 퐺푆푇푗−1) (3.11) where S is a constant representing the maximum number of satellites, i.e. the maximum number of times the function F is executed in one authentication frame. The main drawback of this approach compared to the use of one key per authentication frame is that it requires a higher computational power, as the number of one-way operations per chain is higher. For example, if S=40, the chain would become 40 times longer. The assessment of the additional CPU needs for this approach is covered in a later section.
Figure 12 and Figure 13 present how the keys of a certain chain would be transmitted and used every time the receiver performs an authentication. The discontinuous lines of Figure 13 for the keys imply that the receiver (Rx) only needs to receive a key from one satellite to authenticate all MACs.
For example, if authentication frame j lasts 10 seconds (TBA=10s), every 10 seconds 2 each satellite would send at least one MAC generated with Kj,1 = F(Kj,2,GSTj) = F
F(Kj,3,GSTj), etc. Kj,1 would also be transmitted from SVID (Space Vehicle ID) 1, while
SVID 2 would transmit Kj,2, SVID 3 would transmit Kj,3, and so on. In this way, a spoofer would not be able to predict the key of one satellite from another. One could argue that if
SVID2 is closer than SVID1 to the receiver, an attacker could predict Kj,1 by receiving previously Kj,2 from the closer satellite. However, as the transmission of the keys is done
56
in parallel during some seconds, only the very few final bits of Kj,1 could be predicted by having a high amount of bits of Kj,2, rendering such an attack rather impractical. User implementations should discard the last bits of the key in the anti-replay statistics.
Figure 12 – TESLA one-way chain with different keys from different senders
Figure 13 – TESLA single-chain approach with a different key transmitted by each sender. No cross- authentication To finalise the description of the proposed concept, the generation of the MACs transmitted by each satellite can be performed as follows:
푀퐴퐶푗,푖,푙 = 푡푟푢푛푐(푛, 푚푎푐(퐾푗,푀퐴퐶, (푖 || 푙 || 퐺푆푇푗 || 퐶푇푅 || 푃푗,푙))) (3.12) where 푀퐴퐶푗,푖,푙 is the MAC for frame j transmitted by satellite i to authenticate the navigation of satellite l (note that i and l can coincide, when the satellite self- authenticates); 푡푟푢푛푐 is the truncation function to the n MSB, GSTj is the Galileo system time associated to authentication frame j; CTR is a counter with the position of the MAC in the transmission; and Pl,j is the navigation data from satellite l at frame j to be authenticated. Note that, following the cross-authentication approach, each satellite
57 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION transmitting authentication can transmit several MACs, for itself and the neighbouring satellites. Examples of typical MAC functions used are HMAC-SHA-256, as standardized in [49], and CMAC-AES, standardized as Algorithm 5 in [50].
3.5.4. TESLA and "Cross-Authentication"
Due to the current architecture of the Galileo system, only satellites connected to ground may be able to transmit authentication information. This means that, in the full operational capability, the percentage of connected satellites transmitting authentication information can be approximately between 2/3 and 4/5 of the total number of satellites (next Galileo generations may overcome this limitation). The navigation data of the remaining satellites can be data-authenticated by these satellites: Several MACs can be transmitted for each MAC-Key section, allowing to "cross-authenticate" some satellites by others.
Figure 14 – TESLA single-chain approach with connected (2,4) and non-connected (1, 3, 5) satellites Figure 14 shows how satellites 2 and 4 can authenticate their own navigation (N2, N4) and cross-authenticate the surrounding (non-connected) satellites 1, 3 and 5. This scheme may lead to duplications in the transmitted information (e.g. MAC(N3,Kj) in the figure) or to the reception of authentication for satellites out of view. However, it ensures the authentication of all the navigation information received by all users on earth, at least by Galileo and potentially by other GNSS.
58
3.6. An NMA Proposal for Galileo Signals
This section presents a concrete NMA proposal for the Galileo I/NAV message structure. One of the drivers for this proposal is that it does not require any modifications in the Galileo core system infrastructure, other than extending its input interface to accommodate more bits in the "Reserved 1" field described below. This would permit Galileo to offer an NMA service in the next few years very easily. The NMA proposal performance could be improved by further modifications of the Galileo satellites and ground segments.
The Galileo E1-B I/NAV message structure is based on the transmission of a full navigation frame every 750 seconds. The frame is composed by 30-second subframes, which always transmit all the required positioning parameters except the almanac. Every subframe is divided in 15 2-second pages, each of which contains one word and some other fields, as shown in Figure 15. 120 bps can be transmitted in the E1-B I/NAV message, which are convolutionally encoded into 240 sps, interleaved and appended to a 10-symbol synchronisation pattern for a total of 250 sps. The E1-B symbol stream is modulated through a DSSS (Direct Sequence Spread Spectrum) technique with 4092- chip pseudorandom codes at 1.023 Mcps, and with a subcarrier at 1.023 MHz to achieve a BOC(1,1) modulation. Thus, every 4-ms symbol is modulated within a single 4-ms code. All the details about Galileo I/NAV signals and message can be found in the Galileo Open Service Signal-In-Space Interface Control Document (OS SIS ICD) [12].
The field named as "Reserved 1" in the ICD [12], also known as ERIS (External Regional Integrity Service) field or EDBS (External Data Broadcast Service) field, and currently unused, is proposed to transmit NMA information. This field provides a bandwidth of 40 bits every other second. Galileo is designed to receive the bits of this field from an external source. Thus, by using this field, the Galileo system can provide NMA into the Galileo core infrastructure, minimizing the impact at core system level of adding NMA. In addition, the scattering of the bits across the navigation message allows reducing MPT.
Figure 15 presents the Galileo E1B I/NAV message structure and the position of the "Reserved 1" field in it, and Figure 16 shows the position of the "Reserved 1" field within an E1-B I/NAV word.
59 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 15 – Galileo E1B I/NAV subframe message structure The 40 bits-per-2-second bandwidth yields 20 bps for a total of 600 bits every I/NAV subframe, after which, in nominal conditions, the I/NAV words are repeated. This 30- second subframe structure has also been taken as a reference for NMA, to facilitate synchronization between the reference time, the authenticated navigation data, and the authentication data. The authentication message structure is therefore synchronized with the Galileo I/NAV navigation message structure.
60
Figure 16 – "Reserved 1" field in each I/NAV Word The full use of the 20 bps of the I/NAV E1-B "Reserved 1" field allows very low TBAs and a high cross-authentication redundancy, both of which increase robustness and performance. The high amount of spare bits in the current Galileo I/NAV makes the full use of this field for NMA a reasonable design decision, leaving other spare bits for future uses.
This section describes the data structure in which the authentication information can be provided in the Galileo SIS. It also describes all the fields and their possible values. The main data blocks of the NMA proposal are presented in Figure 17. The SIS authentication information is based on two main sections:
"H-K-root" (Header and Root Key) section: This section includes the global header and a digitally signed root key. In fact, the header and the K-root parts can be considered as separate sections. "MAC-K" (MACs and Key) section: This section includes the MACs and associated key, delivered later. Three MAC-K sections are shown, for authentication frames j, j+1 and j+2, each of 10 seconds, as TBA is 10 seconds. The number of MAC-K sections, as well as other parameters, is dynamically configurable for each chain.
The authentication service is mainly based on the MAC-K section, which occupies 32 out of the 40 bits per word, while the H-K-root section occupies the remaining 8 bits.
61 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
t[s] 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15
MAC-K-1 MAC-K-2 MAC-K-3 (MAC-K sections)
MACS KEY MACS KEY MACS KEY
DSM (H-K-root section) DS DS header Header
Figure 17 –NMA proposal within the Galileo I/NAV message structure The top row of Figure 17 shows the subframe time, which goes from zero to 30 seconds. The second row shows the page order, from one to 15. For every page, 40 bits are available for NMA. To authenticate the keys of the MAC-K section, a root key (K-root) is sent with a digital signature in the H-K-root section. In addition to the SIS information, the system shall provide a public key to authenticate the K-root through other means than the SIS, allowing the verification of the root key.
The following sections provide a general description of the NMA fields. To improve the readability of this chapter, the detailed, bit-level definition of each field and possible values is presented in Appendix B.
3.6.1. H-K-root Section
A global header and a digitally signed root key is provided in this section allowing the user to verify the root key authenticity through a public key. H-K-root (Header and K- root) is transmitted in the first 8 bits of each EDBS 40-bit field. The K-root section ensures that an authentic [K-root, K-root Time] pair is known to the receiver, allowing it to validate a key of the chain received in the MAC-K section. Chains may be several months long, so the receiver will seldom need to decode this section, as it can work with a previously loaded K-root, either from a previous certificate, or from a previous K that is considered authentic (by a K-root).
One of the reasons to transmit H-K-root in parallel with the other fields (keys and MACs), as opposed to sending it in some full EDBS 40-bit fields, is that in the latter case the signal may be predictable during this time, therefore increasing maximum predictable time of the signal and potentially weakening the service protection against replay attacks.
62
In addition, separating H-K-root and MAC-K sections allows more flexibility in the solution design by removing cross-dependencies.
H-K-root is transmitted synchronously with the I/NAV subframe. That means that each subframe a full block is transmitted. Each block is 8 bits * 15 words = 120 bits long. Figure 18 presents the structure of the H-K-root section, including all the fields.
Figure 18 – H-K-root structure and fields (see Appendix B for more details) The main data blocks of the H-K-root section are the Header, DS-Header, and DSM (Digital Signature and Message):
Header: At the beginning of each subframe, the global authentication header is transmitted. It occupies 16 bits (i.e. two words, or 4 seconds in the I/NAV structure) and it is repeated in each subframe. It includes the system operational status and the flags required for chain and management (OS, CID, EOC and NKR). It also contains the information of the digital signature to be transmitted in the remaining 104 bits of the subframe (Digital Signature ID and Block ID).
DS-Header: It is the Digital Signature Header transmitted at the beginning of a digital signature (i.e. only in the first subframe), and contains the number of blocks it occupies (NB) and the ID of the public key used for its generation (PKID).
DSM: Digital signature (with or without recovery) authenticating the K-root and its associated parameters: Chain ID (CID), Key Size (KS), Hash Functions (HF), MAC Function (MF), MAC Size (MS), and time associated to the K-root (WN-Kr and DOW- Kr, for Week Number and Day Of Week). A pattern may be added after the K-root in the case of digital signatures with message recovery. See Appendix B for more details.
63 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 19 shows an example of the transmission of a full H-K-root in the I/NAV subframe structure. In the proposed example, the transmission lasts 5 subframes per satellite (i.e. 150 seconds) and the DS and message (DMS field) length is 512 bits.
field H DSH DSM(1/5) length [b] 16 8 96 H DSM(2/5) 16 104 H DSM(3/5) 16 104 H DSM(4/5)
16 104 H DSM(5/5) 16 104
Figure 19 – H-K-root example in five subframes/blocks By knowing the DS ID and the Block ID, a receiver can reconstruct a K-root easily, even if different K-root blocks were transmitted at the same time from different satellites. In principle, there is no reason to change often the DS-ID, which would facilitate the authentication process, as the same K-root would be transmitted continuously from all satellites for long periods. A K-root update will only be mandatory for every new chain, and the change of chain is expected to happen between once every several weeks, to once every several months, depending on the chain key length and other security considerations.
t t+30s t+60s t+90s t+120s t+150s SV1 I1,B1 I1,B2 I1,B3 I1,B4 I1,B5 I2,B1 SV2 I1,B2 I1,B3 I1,B4 I1,B5 I2,B1 I2,B2 SV3 I1,B4 I1,B5 I2,B1 I2,B2 I2,B3 I2,B4 SV4 I1,B1 I1,B2 I1,B3 I1,B4 I1,B5 I2,B1 Figure 20 – H-K-root / header / number of blocks field Figure 20 shows an example of a 5-block digital signature recovery where block transmission is offset between satellites. The receiver only needs to decode the blocks in dark orange to obtain a certified K-root. The blocks in light orange are redundant blocks of DSID1. Assuming the receiver can receive SV1 to SV3 in good conditions, it would complete a K-root in two subframes, or one minute.
A receiver does not need to receive a whole block correctly from one satellite. It can just reconstruct a certain block from different satellites, by aggregating the 8-bit parts
64
received correctly from different I/NAV words. This can be verified e.g. by checking the CRC (Cyclic Redundancy Check) validity of an I/NAV 2-second word, which includes the EDBS field. If the CRC check is correct, that means that the 8-bit H-K-root portion of that word should be valid as well.
3.6.2. MAC-K Sections
This section is transmitted in parallel to the H-K-root and contains the truncated MACs and keys that are delivered later, from which the key used for the MACs computation can be derived. As the H-K-root section consumes 120 bits per subframe, the remaining 480 bits are available for the MAC-K section.
The currently foreseen length of keys and MACs is 80-128 bits and 10-20 bits respectively. Thus, one, two or three keys can be sent every subframe, one every 30, 15 or 10 seconds, respectively, with its associated MACs. This allows frequent authentications to constrain the potential attacks. As mentioned before, the MAC and key size is configurable for every chain, and fixed when the K-root is sent in the H-K-root section.
For the remaining of this chapter, a scheme with three MAC-K sections per subframe is analysed. This means that the 480 bits available for the MAC-K sections will be divided in three MAC-K sections of 160 bits each.
Figure 21 depicts the structure of the MAC-K section. 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 key is put in the next column, and so on. The order in which the information is received by a receiver is given by reading each row from left to right, and then from top to bottom.
Figure 21 – MAC-K section structure (see Appendix B for more details)
65 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
The receiver can determine how many MACs are transmitted per MAC-K section by knowing the key and MAC sizes, and assuming a predefined number of MAC-K sections from the NMA specification document. If not, an additional field in the K-root message can be added to specify the number of MACs.
The MAC-K sections are identical in format. Each one is composed of several MACs, each one with a 'MAC-Info' field (equivalent to the header), providing information about the MAC. The reasons why the MAC-Info field is appended as a tail and not a header before the MAC are that, first, it increases the distance between the last MAC and the transmission of the key. Second, it prevents the case in which, due to I/NAV encoding and interleaving, a significant number of bits of the key are delivered before some bits of the MAC. While an attack based on this feature seems difficult, the design should prevent an early key disclosure in any case.
The main data blocks of each MAC-K section are the MAC, the MAC-Info and the key:
MAC: Truncated MAC (from the MSB) with the length as defined in the MAC Size field of the DSM section. Typically, the permitted values are between 10-20 bits. In addition to the data, the MACs authenticate also the system time and the SVID in the following way:
푚 = (푆푉퐼퐷_푁 || 푆푉퐼퐷_퐴 || 퐺푆푇 || 퐶푇푅 || 푛푎푣푑푎푡푎) (3.13)
푡푎푔 = 푡푟푢푛푐(푛, 푚푎푐(퐾, 푚)) (3.14) where m is the message to be authenticated, SVID_N is the satellite ID being authenticated as defined in the MAC-info section, SVID field; SVID_A is the satellite ID providing authentication as defined in the MAC-info section (it can only be a Galileo satellite). When NMA status is in 'test' mode, SVID_A = 0 (see Appendix B for more details); GST is the Galileo system time (seconds), as per [12], of the start of the subframe in which the MAC is transmitted6; CTR is a counter with the position (8-bit uint) of the MAC in the MAC-K section. E.g. if the MAC is going to be transmitted first, CTR=1; navdata is the navigation data authenticated as defined in the MAC-info section, ADKD (Authentication Data and Key Delay) field (see definition below); tag is the
6 For offset MAC-K sections (SVID 16 onward) the subframe taken for the time reference will be that if no offset were applied. Note that with the current implementation this is irrelevant anyway.
66
truncated MAC transmitted in the signal; trunc(n,p) is the truncation function whereby the message p is truncated to the n MSB; n is the truncated MAC length, as defined in the DSM; mac is the MAC function used, as defined in the DSM; and K is the key from the one-way chain used for the MAC.
If the SVID were not added to the MAC, given that all MACs in a MAC-K section are signed with the same key, an attacker could forge the signal and transmit the same navigation data from several satellites, and later replay the first MAC. This attack is prevented by adding the SVID to the authenticated message.
The GST is added to make the message to be signed always different and increase robustness, as the navigation data may be updated only every hour or so. However, even if it were not added, the MACs would be unpredictable in the current NMA proposal, as they use a different key every MAC-K section. The signal time is authenticated just by ensuring the authenticity of a key vs the K-root: if a key of a certain subframe is authenticated using the TOW of that subframe, the TOW must be authentic too as, otherwise, the hashing process would not lead to the K-root.
MAC-Info: It identifies the MAC just transmitted, by telling to which satellite the authenticate data corresponds (SVID), what is the Issue Of Data associated (IOD), and what kind of data is authenticated, and the latency between the MAC and the key (ADKD). Due to its importance in the concept, the ADKD is described in more detail. Its values are presented in Table 2.
67 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Table 2 – ADKD parameter proposed definition
ADKD Definition (TBC) 0 Eph&Clk 1 IonoBGD 2 Subframe 3 Gal F/NAV Eph&Clk 4 GPS L1C Eph&Clk 5 SBAS TBC 6 Rsvd 7 Rsvd 8 Rsvd 9 Rsvd 10 Rsvd 11 SLOW-MAC, Eph&Clk, 1 subframe delay 12 SLOW-MAC, Eph&Clk, 2 subframes delay 13 SLOW-MAC, Eph&Clk, 3 subframes delay 14 SLOW-MAC, Eph&Clk, 4 subframes delay 15 SLOW-MAC, Eph&Clk, 5 subframes delay
The proposed meaning of ADKD bits for Galileo is:
'0', eph&clk: the MAC authenticates the bits of the fields related to the ephemeris, including clock corrections, of the given satellite. '1', ionoBGD: the MAC authenticates the bits of the fields related to the ionospheric corrections, Broadcast Group Delays (BGDs), satellite health and Galileo time. '2', subframe: the MAC authenticates the bits of a certain full subframe. '3', Gal F/NAV eph&clk: the MAC authenticates the ephemeris and clocks of the F/NAV message. '11' to '15', "slow MACs": As described in [46], a requirement of the TESLA protocol is a loose time synchronisation between the sender and the receiver. In order to prevent attacks whereby the attacker would rebroadcast a right key with forged navigation and MACs, which could happen if the receiver has a time uncertainty in the order of the seconds between the reception of the MACs and the key, the concept of "slow MACs" is added. A "slow MAC" is a MAC generated with a key that will be broadcast with some subframes of delay.
Key: this field contains the key.
68
3.6.3. Bandwidth Allocation Analysis
The figures in Appendix A present a bandwidth allocation analysis for different MAC lengths and key lengths. Based on this analysis, lengths can be selected to avoid having unused bits in the MAC-K sections. The figures in Appendix A show, for a given number of MAC-K sections per subframe and a given length of MACs and keys, the number of MACs that can be transmitted and the spare bits per MAC-K section, among other parameters. With these constraints, Table 3 and Table 4 show combinations that yield all 160 bits used (3 MAC-K sections / subframe) and all 240 bits used (2 MAC-K sections / subframe), respectively, and the achievable number of MACs per MAC-K section. By keeping a truncated MAC length of 10 bits, and a key length of 82 bits or less, three MACs per MAC-K section can be transmitted, for a total of 9 MACs, i.e. a maximum of 9 data-authenticated satellites per channel, every 30 seconds.
Table 3 - Number of possible MACs for a given MAC length and Key length combination using the whole bandwidth. 3 MAC-K sections per 30-s subframe – 10s TBA
Key size MAC size [bits] Number of Number of Number of keys [bits] MACs per MACs per 30- per 30-seconds MAC-K section seconds 82 10 3 9 3 88 20 2 6 3 90 19 2 6 3 92 18 2 6 3 94 17 2 6 3 96 16 2 6 3 98 15 2 6 3 100 14 2 6 3 102 13 2 6 3 104 12 2 6 3 106 11 2 6 3 108 10 2 6 3
Table 4 - Number of possible MACs for a given MAC length and Key length combination using the whole bandwidth. 2 MAC-K sections per 30-s subframe - 15s TBA
Key size MAC size [bits] Number of Number of Number of keys [bits] MACs MACs per 30- per 30-seconds seconds 80 16 5 10 2 84 10 6 12 2 85 15 5 10 2 90 14 5 10 2 95 13 5 10 2 96 20 4 8 2 100 12 5 10 2 100 19 4 8 2 104 18 4 8 2
69 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
105 11 5 10 2 108 17 4 8 2 110 10 5 10 2 112 16 4 8 2 116 15 4 8 2 120 14 4 8 2 124 13 4 8 2 128 12 4 8 2
With the current proposal, each satellite could transmit three keys per subframe (one every 10 seconds), and transmit 9 MACs in total (3 per key) (see first row of Table 3) which gives a highly performant authentication solution. The fast key update can be also useful if Galileo signal evolutions allow for encoding parts of the spreading codes with the keys later delivered.
In the rest of this chapter, we use as the baseline proposal three MAC-K sections with 10-bit MACs and 82-bit keys.
3.7. A Proposed Implementation in the Galileo System and Facilities
3.7.1. NMA Architecture
The NMA service proposed uses data in the E1-B I/NAV EDBS (former ERIS indirect link) bits (20 bps in E1-B), currently unused in the Galileo system. EDBS is received by the Galileo core infrastructure from an external source. This external source can be the European GNSS Service Centre (GSC), which will be accredited in any case to be connected in real time to the Galileo core infrastructure to deliver the Galileo Commercial Service [27]. The NMA proposal can based on Galileo already existing features, as follows:
The GSC specification foresees the interface for the transmission of E6 data already and a framework to transmit EDBS data in similar conditions. The transmission of EDBS data can be incorporated into the interface specification between the Galileo Ground Mission Segment (GMS) and the GSC. The latency for EDBS data transmission within the core infrastructure is assumed the same as that for E6 data transmission, and in the order of 6 seconds. As explained below, the proposed concept is not very sensitive to system latency. The GSC already foresees to connect in real time to the GMS to transmit E6 data and receive real-time information from the system. Therefore, security
70
accreditation activities already foreseen for the GSC can be leveraged to allow the transmission of EDBS data.
Figure 22 presents the basic architecture on which the proposed NMA could be implemented in the Galileo system.
Figure 22 – NMA Architecture An NMA generation module, which could be integrated within the GSC secured perimeter, receives I/NAV data in real time from the GMS. This information is already available in the current interface. This interface already includes GPS ephemeris data, so GPS could be also data-authenticated. The NMA generation module authenticates I/NAV data, which is sent by the GSC to the GMS through the ERIS/EDBS channel (already built in the GMS). The Galileo Control Centre (GCC), through its Message Generation Facility (MGF) incorporates the EDBS information and transmits it to the Up-Link Station (ULS) for uplink to the connected satellites. The connected satellites transmit the authentication data interleaved with the E1-B I/NAV message in the ERIS/EDBS field, and the users authenticate the I/NAV with the EDBS authentication information and a public key already in their receivers. This public key is published and certified as correct.
3.7.2. System Latency and User Performance
Following the proposed architecture, there will be latency between data is received by the user and authenticated by the system. This section analyses the impact of this latency in user performance. In the current system, this latency can be down to some seconds (thanks partly to the inherited Galileo safety-of-life architecture). For the remaining, we
71 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION assume an end-to-end latency of 12 seconds, twice the foreseen 6 seconds by design, and therefore considered affordable in the Galileo system. We also assume a delay in the authentication process of a full 30-second subframe (except when noted). This means that if new data is transmitted by the system, it will not be authenticated until one subframe later. This is a conservative assumption given that every subframe, up to three authentication events (one every 10 seconds) can take place, according to the current authentication definition.
The main reason why latency will have little impact in NMA performance is that a user already tracking data-authenticated signals and calculating authenticated PVT can continue navigating using authenticated data. I.e., when a new IODnav is transmitted by the system but not yet authenticated by the NMA generation module, the user receivers will still use the previous IOD until the next subframe, in which the new IOD is authenticated. This will pose no or minimal degradation in the navigation performance during 30 seconds, as illustrated in Figure 23.
Figure 23 – Authenticated PVT as a function of IODnav of a given satellite during IODnav transition The only authentication event whose latency can have an impact in the user performance is the ephemeris authentication type (ADKD=0). Delay in providing authentication of ionospheric parameters ('ionoBGD', ADKD=1) has no impact in authentication performance as the ionospheric parameters are foreseen to be updated very seldom, and navigation performance is not foreseen to be altered by using the previous ionospheric parameters. Also, by receiving E1-B and E5b I/NAV messages, the NMA generation module can receive the Iono word (Word 5) before the 6th second of a subframe from E5b, and send it by the end of the E1-B subframe, so authentication of ionospheric parameters could even take place within a given subframe, with a 12-second latency.
3.7.2.1 Impact in a Stationary User
We assume that an IODnav is never updated more frequently than once every 10 minutes (5% of subframes), and normally around once every hour (0.8%). IODnav changes will not occur simultaneously for several satellites in view by the user, at least for Galileo,
72
minimising the overall effect, if any at all, of using older ephemerides in the PVT computation.
Therefore, the impact in a stationary user, i.e. a user already computing data- authenticated PVT, due to the authentication system latency is minimal. However, any guidelines for receiver implementation must state that the data-authenticated PVT service relies on the usage of the latest authenticated data, even if newer data is available.
3.7.2.2 Impact in TTFAF
This section presents the impact of system latency in TTFAF data authentication in cold start mode. We assume that:
The receiver has neither any IODnav nor any recent MAC-key information. It does have a certified and valid K-root. The user needs one full subframe to process all necessary navigation data to compute a first PVT (mainly ephemeris, ionosphere, and TOW). The user needs one full subframe to process all authentication information necessary for a data auth-PVT (mainly MAC sections from satellites and at least 1 key).
In this situation, authentication latency would only impact the case in which a user receives as first subframe containing IODnav(i+1) and Auth(IODnav(i)), as e.g. between T0+30s and T0+60s in Figure 24. In a nominal scenario, one can assume that the satellites whose IOD is being updated are a minority, and that the user will still have enough satellites in view whose IOD is not updated, therefore causing no degradation at all for the TTFAF even in this case, i.e. TTFAF will be the same as TTFF. Therefore, in a nominal scenario, even if the user switches on its receiver at an IODnav change, its TTFAF will not be affected.
In a worst-case scenario, in which the updated IODnav satellites are necessary for the PVT and therefore for the first fix, the user receiver might need to wait for another subframe (30s) to receive the new authenticated IODnav. This situation seems very unusual. Even if it happened, the NMA module could receive a new IODnav from E1 and E5b (which transmit the both the same I/NAV message, but in different order), assuming a latency of 12 seconds, and would still have time to transmit it to the user within the subframe, as shown in Figure 24.
73 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
I/NAV word E1B 2 4 6 7 or 9 8 or 10 rsvd rsvd rsvd rsvd rsvd 1 3 5 spare spare E5B 1 3 5 7 or 9 8 or 10 rsvd rsvd rsvd rsvd rsvd 2 4 6 spare spare time [s] 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 end-to-end latency: 4s-16s subframe time to transmit new IOD authentication: 16s-30s
Figure 24 –"Optimised" authentication transmission to authenticate IODnav from the same subframe (eph&clock I/NAV words 1, 2, 3, 4 marked in grey) Therefore, with an optimised NMA implementation, and under the current assumptions, TTFAF can be the same as TTFF in all cases.
As regards anti-replay protection, in case the unpredictability of the authentication information is used for signal (and therefore pseudorange) authentication, the same as for data authentication applies, i.e. in most cases the user receiver will have all the elements available to perform an authentication verification.
3.7.2.3 Examples
In order to illustrate the above cases, we analyse some examples. In the current examples, we assume that 30 seconds are elapsed between data is transmitted in the I/NAV by the core infrastructure.
Example 1 – Stationary case – IODnav change: a user is performing authenticated PVT with IODnav(i) and authentication data for IODNav(i). In a given subframe, the system updates the navigation data to IODnav(i+1). For this subframe, the user will receive IODnav(i+1) and authentication of IODNav(i). The user can navigate with IODNav(i) authenticated data, and re-authenticate IODNav(i) to protect against replay, until both IODnav(i+1) and authentication of IODnav(i+1) are received in the next subframe.
Example 2 – Cold start – no IODnav change: a user switches on its receiver. Once the signals are acquired, it starts demodulating the navigation data. As the IODnav is not changed, the user will get at the same time the navigation and the authentication for this navigation data, even if authentication data has a latency of 30s. Once it has received the navigation and authentication data, it can continue re-authenticating the data to ensure it is not subject to replay attacks.
Example 3 – Cold start – IODnav change: a user switches on its receiver. Once the signals are acquired, it starts demodulating the navigation data. As the IODnav has changed, the user will get at the same time the navigation data of IODnav(i+1) and the authentication data of IODNav(i). It will be able to start navigating with IODnav(i+1),
74
but it cannot authenticate this data with the authentication information. It needs to wait at most 30 seconds (the latency assumed in this case) to receive authentication information for IODnav(i+1), in order to authenticate IODnav(i+1).
Example 4 – Warm start – IODnav change: a user switches on its receiver. Once the signals are acquired, it starts demodulating the navigation data. As the IODnav has changed, the user will get at the same time the navigation data of IODnav(i+1) and the authentication data of IODNav(i). However, as the user already has IODNav(i) data, it can navigate temporarily with this data (which should not be degraded, as it is only 30- seconds beyond its foreseen applicability time), until authentication for IODnav(i+1) is received.
We can conclude that an end-to-end latency in the order of some seconds will not have a significant impact in the NMA, neither in stationary mode nor for TTFAF, which should remain the same as TTFF. The current system architecture should therefore allow latencies with enough margin to perform NMA as proposed.
3.7.3. Message Losses
Data losses in the transmission of data authentication through the system loop lead to unsuccessful authentication events. Events in the data transmission should be reported to the user, for example by the broadcast of an EDBS dummy message, as opposed to a wrong or corrupted message, as otherwise they may have an impact on the spoofing detection logic. This way, the user can detect an error in the system transmission and flag the unsuccessful authentication accordingly. Data transmission events leading to a missing/dummy EDBS field in a given I/NAV word while a satellite is connected can be any of the following:
Late packets, i.e. arriving after the reception window is closed anywhere in the chain. Corrupted packets. Lost packets.
We can characterise the affordable data transmission events as follows:
n 1 – SAER = (1- Perr) (3.15)
75 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION where SAER is the System Authentication Error Rate, i.e. the rate of authentication errors due to the system, Perr is the probability of error of an EDBS packet, and n is the number of EDBS packets required for a successful authentication event. We propose the following numbers for this preliminary analysis:
SAER = 0.001, i.e. at most, one out of 1000 authentications can be wrong due to a system issue, when a satellite is stably connected to ground. n = 5. There is an authentication verification every 10 seconds (following the MAC-K section definition in other sections), involving 5 full 40-bit EDBS packets in E1-B I/NAV, i.e. 5 packets need to be correctly received for a successful authentication.
Table 5 presents a preliminary analysis of data losses in the transmission chain. They are approximations of what data loss ratio would be tolerable to achieve a SAER in the order of 0.001. The Space segment to GMS step loss is assumed to be 1 as it is considered that the redundancy in the monitor network will allow the GMS to receive the navigation data from all constellation satellites from at least one station.
Table 5 – NMA data losses vs. System Authentication Error Rate
Step (1 - Message loss) (1 - Message loss) Space to GMS 1 1 GMS to NMA Module 0.9999 0.99999 NMA Module to GMS 0.9999 0.99999 GMS to Uplink Station 0.9999 0.99999 MEO Uplink 0.9999 0.99999 Total message correct transmission 0.99960006 0.999960001 (1-Perr) 1 – SAER 0.998001899 0.999800019 SAER 0.001998101 0.000199981
The table shows that, to achieve a SAER in the order of 1/1000 (0.001998 particularly), all steps in the chain would require a data transmission success ratio of 99.99%, i.e. 1 faulty transmission out of 10,000.
3.7.4. Downlink Requirements
The proposed NMA can be defined as a data authentication service or a data and time-of- arrival authentication service. In case of data authentication only, the service is provided if the system data-authenticates four or more satellites within an I/NAV subframe (30
76
seconds), which can be achieved with one connected satellite in view. In case of data and time-of-arrival authentication, the service is provided only if four connected satellites are visible, although it is also useful to characterise the case where only three, or two connected satellites are visible7. The Galileo services are foreseen to rely on 16 connected-to-ground satellites, and the system is currently dimensioned up to 20 connected satellites, though with the potential to increase downlink capabilities in the future.
3.7.5. NMA of Data from Other GNSS
As already mentioned, the proposed architecture can authenticate GPS data. This may be a useful feature, as users will very likely navigate with GPS and other GNSS. If GPS data is not authenticated, the receivers cannot compute a data-authenticated GPS + Galileo solution. Given that the proposed concept allows to data-authenticate up to 9 satellites per connected satellite per I/NAV 30-second subframe, i.e. for maximum 27 satellites every 30 seconds, there is enough bandwidth to provide data authentication for GPS, if estimated convenient.
The process to data-authenticate GPS satellites is similar to that for Galileo satellites, as all satellites for which data available can be treated similarly by the OS authentication module. This is currently the case for the CS Demonstrator authentication solutions, which already authenticated GPS data [27] [51]. As mentioned in 3.6.2.2 (ADKD field), the "MAC-Info" header allows the system to authenticate other GNSS' data.
3.8. Design Trade-Offs
This section presents in detail some justification and trade-offs of some design aspects in the proposed NMA solution. Some parts present some preliminary quantitative assessments to justify the design decision.
7 In the absence of more E1 unpredictable signals in Galileo first generation, the case whereby a user receiver can authenticate a position with less than 4 connected satellites by adding other constraints must be considered as well. These constraints can relate to restrictions in the clock drift, restrictions on the position solution, or information those from other sensors. Appendix D analyses some of these restrictions.
77 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
3.8.1. Cross-Authentication of Neighbouring Satellites
As mentioned before, a solution to Galileo uplink capability constraints is to design a service whereby a satellite can transmit authentication information for other surrounding satellites, as shown in Figure 25.
Auth(P1) P1 P2 P3 P4 Auth(P2) Auth(P3) Auth(P4)
Rx
Figure 25 – Schematic of the cross-authentication approach Figure 25 depicts four satellites, whereby satellites SV1-3 are transmitting standard "plaintext" navigation data (P1, P2, P3), and satellite SV4 is transmitting authentication information for all of them. Satellites 1-3 can be satellites from other GNSS, or satellites that due to the system constraints cannot transmit authentication. The main differentiator of the proposed concept with respect to standard authentication schemes relates to the simultaneous authentication of several sources: In standard authentication schemes, there is one source of information providing both the plaintext and the authentication data (digital signature or MACs). By comparing both, this source can be authenticated. Conversely, in the proposed concept, the senders of the plaintext and the sender of the authentication information are different.
When a satellite cross-authenticates its nearest neighbours, only a subset of all satellites authenticated may be visible to the end user, as shown in Figure 26. Taking any position on earth, and the user masking angle α which describes the cone for which satellite signals are able to reach the user (dashed spherical cap in the figure), we see a proportion of out-of-view satellites that needs to be accounted for in the performance assessment.
78
Figure 26 – Out of view satellites in cross-authentication Four satellites need to be data-authenticated for a data-authenticated PVT. This means that they have to be visible and authenticated by a connected satellite within a 30-second subframe. Following the NMA implementation proposal in this chapter, each connected satellite can authenticate up to 9 satellites (3 MACs x 3 MAC-K sections). For this analysis, we assume that, out of the 9, 1 MAC authenticates the ionosphere and the other 8 are for the satellite to authenticate itself and other 7 satellites, some of which may fall out of the visibility cone of the user. The visible and authenticated satellites will be those in the intersection of the user visibility cap and the satellite Sc cross-authentication cap, as shown in Figure 26. Based on a Monte-Carlo simulation and assuming a uniform satellite distribution in the caps.
Table 6 presents the percentage of out-of-view satellites for different number of MACs per connected satellite and masking angle. We see that, for a masking angle of 25º, and 7 MACs, the average percentage is 45%, i.e. more than 3 visible satellites would be authenticatable, even with only one satellite connected. If we have more connected satellites in view, the average number of visible-and-connected satellites will be increased. This means that the proposed approach of three MAC-K sections with three 10-bit MACs each seems adequate, even in degraded conditions. Other approaches transmitting more MACs per subframe yield even better performance.
79 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Table 6 - Percentage out-of-view satellites as a function of the number of MACs and the masking angle – source: L. Bogaardt, EC.
MACs per connected satellite
1 2 3 4 5 6 7 8 9 10 11 12
5 10.8 15.9 19.7 22.8 25.7 28.3 30.6 32.9 35.1 37.2 39.3 41.2
10 12.6 18.1 22.1 25.5 28.6 31.4 33.9 36.5 38.9 41.2 43.4 45.5
15 14.4 20.1 24.4 28.0 31.3 34.3 37.2 39.9 42.5 45.0 47.4 49.7
20 16.4 22.6 27.3 31.3 34.9 38.2 41.4 44.4 47.2 49.9 52.5 55.0
25 17.8 24.5 29.7 34.0 38.0 41.6 45.0 48.2 51.2 54.1 56.8 59.4
30 19.2 27.1 33.0 37.8 42.4 46.4 50.1 53.5 56.8 59.9 62.7 65.4
Masking angle 35 20.8 29.6 36.0 41.4 46.3 50.6 54.5 58.1 61.6 64.7 67.6 70.3
40 23.3 32.9 40.1 46.3 51.6 56.2 60.5 64.3 67.8 70.9 73.5 75.8
45 26.2 36.4 44.7 51.5 57.2 62.1 66.5 70.3 73.6 76.2 78.4 80.2
50 28.8 40.7 50.7 58.3 64.5 69.6 73.9 77.1 79.7 81.7 83.4 84.8
3.8.2. Digital Signatures vs. Time-Delayed Asymmetry
To maximize the use of GNSS authentication, cryptographic key management should be simplified as much as possible. This means that asymmetric schemes, whereby the user receivers need only to possess a public key, are preferred to symmetric schemes, whereby the user needs to store a secret key in a security module within the receiver. Asymmetric schemes can be achieved mainly through two ways:
Digital signatures, as RSA, DSA or ECDSA [10]. In these schemes, the satellites transmit a digital signature of their navigation data, as described in [4]. Delayed symmetric key delivery, as TESLA.
The main advantage of authentication through digital signatures is that there are known methods and functions in the cryptographic standards that make them reliable for the cryptographic community. The main disadvantage of authentication through digital signatures, compared to time-delayed symmetric approaches, is the bandwidth required to transmit the authentication information. For example, in order to transmit a digital signature that guarantees a 112-bit to 128-bit level of security, signatures in the order of
80
500 bits are required (e.g. 512 bits for standard DSA, 128-bit security, or 466 bits for 112-bit security through ECDSA, as per [23]). Other disadvantages may include the computational effort required per authentication, and the fact that some elliptic curves may be subject to patent rights.
The main advantage of schemes based on the delayed delivery of a key used to generate a previously sent authentication code, as TESLA, is the bandwidth reduction and the tolerance to data loss. Their main disadvantages may be that they are not as standardized and accepted by the cryptographic community as digital signatures are, and their design must protect the user against more threats, as they rely on a coarse time synchronization of the receiver with a time reference.
In any case, to authenticate the signal-in-space (SIS), the receiver must possess some information that is certified as correct independently from the signal-in-space. This means that even for TESLA approaches, the receiver must possess a public key to authenticate the SIS. However, the frequency with which this public key is used, and the bandwidth associated to this process, can be very low, if a TESLA approach is used. Combining TESLA with cross-authentication maximises the advantages of TESLA wrt. Digital signatures. For example:
Assuming ECDSA digital signatures of 446 bits (112 symmetric security bits), 4 x 446 = 1784 bits would be required for the authentication of four satellites. Assuming TESLA keys of 112 bits and truncated MACs of 10 bits each, each carrying a 16-bit MAC-info section, 4 x (10 + 16) + 112 = 216 bits would be required for the authentication of four satellites. For the proposed 82-bit keys, the total number is 186 bits.
3.8.3. Staggering of Authentication Events
The introduction of a time offset for subsets of satellites to stagger the authentication verification times can improve authentication robustness. This has been already proposed in [23]. In a fully synchronous scheme with a TBA of 10 seconds, all satellite information would be authenticated every 10 seconds. However, receivers can be subject to attacks during these 10 seconds, only noticing when the authentication verification is performed. If the transmission of authentication information is offset for some satellites, different subsets of satellites would be authenticated at different times, leading to a lower TBA at user level. The Key-to-MAC allocation proposed in this scheme must allow
81 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION minimizing TBA at user level while not compromising other parameters, avoiding the disclosure of the keys associated to MACs before or during the time the MACs are being transmitted. If two subsets of satellites are transmitted at different times, and with the currently proposed TBA of 10 seconds, the system could achieve an average user TBA of 5 seconds. Even if the satellites authenticated every 5 seconds (in average) are less than four, as required to compute a position, a receiver can make use of the pseudorange bounds for increasing its robustness, in combination with other previously authenticated ranges. The main features of the proposed offsetting scheme are:
MAC-K transmission is divided in 2 groups: o SVID1 to SV15 transmit MAC-K sections allowing authentications at seconds 0, 10 and 20 of the subframe. o SVID16 to SVID308 transmit delayed MAC-K sections allowing authentications at seconds 4, 14 and 24. MACs transmitted by SVID1 to SVID15 use the key transmitted from SVID1
(K1) (for clarity, the j sub-index representing the authentication frame is omitted here). This key can also be recovered from a key from any satellite SVID2 to SVID15 transmitted at the same time, or any key transmitted later. MACs transmitted by SVID16 to SVID30 use the key transmitted from SVID16
(K16). This key can also be recovered from a key from any satellite SVID16 to SVID30 transmitted at the same time, or any key transmitted later.
Figure 27 presents this offsetting in MAC & key transmission scheme. It assumes that the first key used in the subframe is K(m+1).
t [s] 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34
SV1 MACS(K(j,1)) K(j,1) MACS(K(j+1,1)) K(j+1,1) MACS(K(j+2,1)) K(j+2,1) … SV2 MACS(K(j,1)) K(j,2) MACS(K(j+1,1)) K(j+1,2) MACS(K(j+2,1)) K(j+2,2) SV3 MACS(K(j,1)) K(j,3) MACS(K(j+1,1)) K(j+1,3) MACS(K(j+2,1)) K(j+2,3) … MACS(K(j,1)) K(j,...) MACS(K(j+1,1)) K(j+1,...) MACS(K(j+2,1)) K(j,...) SV15 MACS(K(j,1)) K(j,15) MACS(K(j+1,1)) K(j+1,15) MACS(K(j+2,1)) K(j+2,15) SV16 … MACS(K(j,16)) K(j,16) MACS(K(j+1,16)) K(j+1,16) MACS(K(j+2,16)) K(j+2,16) SV17 MACS(K(j,16)) K(j,17) MACS(K(j+1,16)) K(j+1,17) MACS(K(j+2,16)) K(j+2,17) SV18 MACS(K(j,16)) K(j,18) MACS(K(j+1,16)) K(j+1,18) MACS(K(j+2,16)) K(j+2,18) … MACS(K(j,16)) K(j,...) MACS(K(j+1,16)) K(j+1,19) MACS(K(j+2,16)) K(j,...) SV30 MACS(K(j,16)) K(j,30) MACS(K(j+1,16)) K(j+1,30) MACS(K(j+2,16)) K(j+2,30)
Auth. Events 6s 4s
Figure 27 – Key-to-MAC allocation and authentication offsetting
8 If higher SVIDs (SVID31, SVID32…) are used, they can be included in the second group.
82
The proposed scheme authenticates half of the satellites at 0, 10, and 20 seconds, and the other half at 4, 14 and 24 seconds, leading to a user TBA between 4 and 6 seconds, with an average time between authentications of 5 seconds. As shown in the figure, the proposed scheme allows the simultaneous transmission of keys and MACs without compromising the system, as the transmitted MACs always use a key that cannot be computed from the keys under transmission.
3.8.4. Security Considerations
3.8.4.1 Single One-Way Chain
By using only one chain for all satellites, if the chain is compromised (i.e. the seed key
Kn is found), the whole system is compromised. However, if a one-way-per-satellite chain is secure, a one-way-all-satellites chain shall be secure as well, due to the following:
The one-way chain security depends on the choice of the hash primitive and hash bit output length. A cryptographically secure design choice for several chains shall be as secure for a one-way all-satellite chain.
For a certain chain interval, instead of protecting several seed keys Kn the system
shall protect only one Kn. The existence of a single vs. multiple parallel chains does not change the system architecture, as the security measures of the system are similar. The choice for the hash function and the key length can be done with enough margins to be considered secure for a much higher duration than the validity period of the chain. For example, if a chain is valid for some months, the design can make it secure
for years. If, due to the higher criticality of compromising Kn, higher security measures are proposed in the system, the validity period of each chain could be shortened, or the key bit length increased, or other system-related measures could be introduced, while maintaining the advantages of the current concept.
In summary, using a single chain for all satellites does not seem to reduce the security of the system.
3.8.4.2 Key Length
As regards the symmetric key length used in the one-way chain, in correspondence with [52] and [53], a key length of 80 bits is considered to be strong enough at the time of writing the thesis for chain durations of up to one year. Robustness of this approach is
83 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION reinforced by including the GST (Galileo System Time) or any other unpredictable input before the rook key is published, preventing pre-computation attacks. Longer keys may be chosen during the lifetime of the system, if needed, and this NMA proposal allows that. For example, if the key has to be guaranteed for e.g. 20 or 30 years, longer keys of e.g. 128 bits would be recommended in the future [54]. To accommodate keys as short as 80-bits in a standard one-way function as SHA-256 [55] or SHA-3 [56], the one-way function needs to truncate the output of the hash function to the length of the key for every iteration in the chain, as shown in Equation (3.8), but this does not reduce the security of the system.
3.8.4.3 MAC Truncation and One-Way Function Truncation
For applications using large data bandwidths compared to the output sizes of cryptographic algorithms, it is common to use MAC functions with output sizes of 80 or even 160 bits, as is the case for some HMAC functions [12]. It should be noted, however, that meaningful levels of security are achieved already with much shorter output sizes.
Given the low throughput available in GNSS signals, the lengths of the key and the truncated MACs are very sensitive parameters. They drive the number of authentication bits (NA), and therefore affect AER and TBA (the latter assuming a fixed bandwidth), which are reflected in all other indicators. Therefore, their length should be reduced as much as possible, while maintaining security to an acceptable level.
Given that GNSS are one-way systems, an attacker has no control over the message that is authenticated (i.e. it cannot request a satellite to authenticate a given message), or the key used, and the MAC and key transmission occurs with a certain cadence controlled by the system specification. This yields some attacks impractical, permitting the use of very short MAC tags. Assuming the MAC algorithm chosen behaves as a lookup table with a message and a key as entries, and an n-bit random sequence as an output, an attacker could only try to guess the MAC, which is very unlikely even for extremely truncated MACs to very few bits [40] [45]. A MAC as short as 10 bits would be guessed with an average probability of 0.097% (one time out of 1024), rendering the "MAC-guessing" attack very impractical compared to a pure service denial by e.g. jamming the signal.
Some additional protections to this attack are:
84
A receiver can accumulate two or more data authentications before accepting the data as authenticated, in order to reduce the "MAC guessing" attack probability. Given the very short TBAs and the possibility to cross-authenticate several satellites, this permits data authentication with higher probabilities with a delay of few seconds, or even without any delay. For example, Let us imagine a receiver that only uses a new issue of data (IOD) which is authenticated twice, reducing the "MAC guessing" probability to 1/(1024)2 and navigating in the meantime with the previous IOD, which should minimally affect the navigation performance. The NMA solution could encrypt each MAC-Info section with the key later delivered, making the "MAC guessing" attack more difficult and adding unpredictability to the signals. This is left for further work beyond this thesis.
3.8.5. Receiver CPU Needs
To understand the computational power required in a single one-way chain scheme where each satellite transmits a different key, state of the art SHA-2 implementations have been looked at. It is claimed that around 11.5 processor cycles per byte are required [57]. As a rough estimation, a 1GHz processor available in smartphones already would need around 0.4 microseconds for one SHA-256 (i.e. 32 bytes) iteration. Other more widespread references, as the benchmarks for Crypto++ libraries [58] suggest 15.8 cycles per byte. For the rest of the analysis, and taking into account that the one-way function may also involve the concatenation of a counter of time reference, and a truncation, one microsecond per iteration is taken.
The CPU required for a single chain multiple-key TESLA approach, assuming 40 hash iterations per authentication (allowing to cover 30+ satellites) would be therefore 40 microseconds for the whole set of satellites every TBA period, as the operation is required only once for all satellites, which in absolute terms is very affordable for a standard low-end processor.
As regards the CPU needed to verify a certain key K against an authenticated root key, which is, for example, associated to a time 1 week before the applicability time of K, assuming 40 hash iterations for a 10-second TBA period, it would require 7 days/week * 24 hours/day * 60 minutes/hour * 2 subframes/minute * 3 authentications/subframe * 40 hashes = 2419200 iterations, i.e. around 2.5 seconds, which is affordable taking into account that this operation may be required very unfrequently. Therefore, the CPU computing power required seems not a major driver. In standard 1-chain-per-sender
85 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
TESLA approach, the chain verification needs to be once computed for each satellite in view, leading to lower computing power needs. However, this does not seem to represent a huge difference in terms of computational feasibility for the receivers.
As a summary, this preliminary assessment shows that CPU power required for a single one-way chain using different keys per satellite is affordable for the CPUs of present and future GNSS terminals.
3.9. Performance Results
This section characterizes the proposed solution mainly in terms of AER, which affects all the high-level indicators. It also assesses the impact of adding authentication in accuracy, availability and time to fix. Introducing the cross-authentication approach makes the characterization not as straightforward as if each satellite were self- authenticating, and this leads to some extra explanations and indicators described below. The performance is principally measured for data authentication. Considerations on anti- replay protection are presented in section 3.10.
Except when noted, the performance analysis covers the 82-bit key, 10-bit MAC and three MAC-K section proposal, with 1 MAC-K section every 10 seconds. We presented other combinations for comparison in some of the results. The characterization below excludes the processing of the H-K-root. It is assumed that the receiver has an authentic K-root.
3.9.1. NMA Availability and AER
Availability is characterised under the following assumptions:
At a given subframe, and given that connected satellites cross-authenticate non- connected ones, the Galileo system is able to transmit the authentication information to all Galileo satellites in view by any user with good visibility. This is a realistic assumption taking into account that each connected satellite is able to transmit 9 MACs in a given subframe, i.e. a total of 18, 27 or 36 MACs, in the case of 2, 3 and 4 connected satellites visible respectively This allows the system to transmit authentication for ionospheric parameters and ephemerides and clocks for all Galileo satellites in view and potentially satellites from other constellations.
86
Given that all data authentication information will be available, the availability will depend on the percentage of this information that is demodulated correctly, which is measured by AER as described below.
Table 7 presents the number of bits required with (NNA) and without (NN) authentication in three cases:
Ephemeris and clocks of one satellite are authenticated Ephemerides and clocks of four satellites and TOW are authenticated. Ephemerides and clocks of four satellites, TOW, BGD and ionospheric information (Word 5) are authenticated.
Table 7 – Number of Bits Required With and Without Authentication
Indicator Number of bits Comments 1 Satellite, Ephemeris and Clock(Words 1-4) Authentication NN1 NN = Number of Galileo I/NAV (Navigation) bits for ephemeris and clock of one satellite (ADKD = 0). It is considered that the required navigation bits to read are all in words 1 to 4 minus the reserved (4) and spare bits (2), i.e. 128 * 4 – 6 = 506. Further optimisations (e.g. not reading word type or IODnav, assuming that they are deterministic) are not considered. 506 They are in any case of little relevance for the calculations. NA1 NA = Number of authentication bits to data-authenticate a satellite 108 MAC-info: 16 bits; MAC: 10 bits; Key: 82 bits NNA1 NNA = Number of Navigation and Authentication bits required to 614 authenticate a satellite (only ephemeris and clock counted) 4Satellites, Ephemerides and Clocks (Words 1-4) Authentication NN4 NN4 = Number of Galileo I/NAV (Navigation) bits for ephemerides and clocks of four satellites. TOW bits are taken into account (We assume WN is known). Therefore, NN4 = NN1*4 + 20, where 20 bits come from TOW. Note also that GST need not be authenticated separately as the time reference is verified as part of the TESLA authentication: if 2044 incorrect, the key vs. K-root verification will fail. NA4 NA4 = Number of Authentication bits required to authenticate four satellites (4 MACs of ADKD=0 type) 186 MAC-info: 4*16; MAC: 4*10; Key: 82 NNA4 NNA4 = Number of Navigation and Authentication bits required to authenticate 4 satellites (only ephemerides, clocks and TOW 2230 counted) 4Satellites, Ephemerides and Clocks (Words 1-4) and Iono-BGD (Word 5) Authentication NN4I NN4I = Number of Galileo I/NAV (Navigation) bits for ephemerides and clocks of four satellites plus ionospheric corrections, BGD and GST (105 bits (128 – 23 spare) from Word 2129 5). NA4I NA4I = Number of Authentication bits required to authenticate four satellites (4 MACs of ADKD=0 type) and "ionoBGD" 212 (ADKD=1)
87 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
MAC-info: 5*16; MAC: 5*10; Key: 82 NNA4I NNA4 = Number of Navigation and Authentication bits required 2341 to authenticate 4 satellites, iono/BGD corrections and GST.
The proposed bit numbers consider that CRC is not required, i.e. the receiver does not reject a full page if CRC fails, as CRC data integrity provision can be replaced by data authentication.
As shown in equation (3.2), AER depends on bit error rate (BER) and number of navigation and authentication bits (NNA) to be demodulated. BER is defined in (3.3) when no coding is applied. In the case of FEC (Forward Error Correction) convolutional encoding of Galileo E1-B I/NAV, the BER can be bounded by the equations below [6], assuming a soft decision Viterbi decoder and a static receiver under an AWGN channel and stable PLL (Phase Locked Loop) tracking:
1 퐵퐸푅 ≤ ∙ (36퐷10 + 21퐷12 + 1404퐷14 + 11633퐷16) (3.16) 2
1 − 퐶/푁0 (3.17) 퐷 = e 2R푏 where Rb is the number of bits per second. Figure 28 shows the BER versus carrier to noise density ratio (C/N0) to give a sense of the reception conditions as per equations
(3.16) and (3.17). AER vs C/N0 is shown in Figure 29 for three cases, where ADKD is '0' (eph&clk), '1' (ionoBGD) and '2' (SF).
Figure 28 – (Maximum) BER of Galileo I/NAV E1-B vs C/N0, AWGN channel
88
Figure 29 –AER vs C/N0 , ADKD=0 ('eph&clk', blue), 1 ('ionoBGD',red), 2 ('SF',green) Figure 29 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 with a C/N0 between 25dBHz and 26 dBHz for all cases. It also shows that below 24 dBHz NMA is barely usable. The authentication performance is thus as good as expected and in line with the I/NAV demodulation performance. A receiver able to demodulate the navigation data should also authenticate with a reasonably high availability.
A receiver in an environment subject to fading may have problems to perform authentication. However, it still can have a high availability by receiving the key from the connected satellite with best visibility conditions, and successfully demodulate some of the received MACs.
Figure 30 and Figure 31 show the different error rates for decoding just the navigation data and for decoding the navigation plus authentication, assuming an AWGN channel. FER-1SV represents the Frame Error Rate (FER) of decoding only the ephemeris and clock of one satellite (words 1-4, NN=506 bits). AER-1SV represents the authentication error rate of decoding the same bits plus the authentication (NNA=608 bits in total). A similar reasoning applies to the 4SV and 4SVI cases. 4SV implies decoding and authenticating the ephemeris and clock data, plus TOW, for four satellites (NN=2044; NNA = 2230) and 4SVI implies decoding the same data as in the 4SV case plus an
89 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION additional word (Word 5) with the ionospheric and BGD corrections (NN=2129; NNA=2341).
Figure 30 and Figure 31 show that there is very little difference in the error rate for the receiver, with or without authentication, at a given C/N0. For example, to achieve the same error rate with authentication, the signal should be only around 0.02 dB more powerful than that without authentication. This power difference is reduced as more satellites are authenticated, as only one key is necessary for all satellites.
Figure 30 – Error rates with and without authentication for 1 satellite, 4 satellites and 4 satellites and 'ionoBGD'
90
-2.1 10 FER-1SV AER-1SV FER-4SV -2.3 10 AER-4SV FER-4SVI AER-4SVI -2.5
10 Error Rates Error -2.7 10
-2.9 10
25.8 25.9 26 26.1 26.2 26.3 C/N0 [dBHz]
Figure 31 – Error rates with and without authentication for 1 satellite, 4 satellites and 4 satellites and 'ionoBGD' – Zoom around 26 dBHz C/N0 (ii) Figure 31 shows, with some more resolution, the different error rates in different cases. -2.28 For example, when comparing the 4SVI case, FER at a C/N0 of 26 dBHz is below 10 or 0.0052, while AER is below 10-2.24, or 0.0058. This means that the degradation in availability from decoding the navigation bits to decoding the navigation plus authentication bits is very low.
In absolute terms, and assuming that a Galileo signal processed with a receiver with a standard noise figure and in good visibility conditions is received with a C/N0 of around 45 dBHz, we can conclude that, even with a power loss of around -18 dB (from 45 dBHz to 27 dBHz), data authentication can be performed at a very low error rate (AER for four satellites is below 10-4). Therefore, and taking into account that all the data required for navigation is authenticated, the degradation of adding the proposed NMA to accuracy and availability standard navigation performance will be minimal (this does not consider any performance alteration due to replay protection processing within the receiver).
3.9.1.1 AER and Availability Comparison of Different Authentication Solutions
As the AER result does not show in an evident way the advantages of the proposed solution compared to other authentication solutions, Figure 32 presents the "four satellite AER" for a given BER. It represents probability that four satellites are correctly authenticated under a noisy channel (AWGN in this case), versus a given BER. For clarity, only NA (as opposed to NNA) has been considered. This may represent the real case whereby a receiver has already received the slow time varying navigation
91 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION information (ephemeris, ionospheric model, etc.), while it still requires successful authentications to verify it is not under a replay attack. The following cases are considered:
1) AER-NA-DS: 466-bit digital signature, one per satellite (112 security bits). 2) AE-NA-STD-TESLA: Standard TESLA approach, with 224-bit keys and 15-bit truncated MACs (224 security bits). 3) AER-NA-1C-TESLA: 1-chain TESLA approach, with 224-bit keys and 15-bit truncated MACs (224 security bits). 4) AER-NA-1C-TESLA-F: Current proposal, with 10-bit MACs and 82-bit keys (82 security bits).
Cases 1) and 2) have been already presented in [45] . Cases 2) and 3) use the same security bits level but illustrate the improvement by using a single chain. Cases 3) and 4) follow the same concept and illustrate the improvement by reducing the security bits level and increasing the MAC truncation. As expected, a lower NA leads to a higher availability of the service in equal conditions, which makes the service more robust. For example, to achieve a 4-satellite NA-only AER of 10% a BER of 5*10-5 in case of a digital signature is required, but only a BER of around 10-3 is required in the "fast TESLA" case described in the current proposal.
Figure 32 – Four-satellite AER vs BER
92
3.9.1.2 Probabilistic Analysis of Authentication Error Rate including Multiple Satellites and Multiple MAC and Key channels
The previous section has calculated the NMA performance based on per-satellite indicators. However, for a user intending to authenticate its data, its performance will be related to the fact that it has multiple channels to receive information that is transmitted several times. This section quantifies data authentication error rate in this scenario, so protection against replay attacks is not taken into account. This analysis relates to data authentication only.
Let us now calculate the probability of authenticating a satellite over a given time interval T. In order to authenticate a satellite, we need correct reception of the navigation, the key and the MAC. Therefore, the probability of performing a successful authentication depends on the probability of correctly decoding a MAC, a key and the navigation data (if not previously available). Let us start calculating the probability of not decoding successfully a MAC of a given satellite:
̅̅̅̅ 푁푀푙·퐶 푀푙 = 푀퐹퐸푅푙 (3.18)
Where 푀퐹퐸푅푙 is the frame error rate of the MAC information packet for satellite l, 푁푀푙 is the number of MACs of satellite l received per channel during T, and C is the number of channels, i.e. the number of connected satellites. In other words, the probability of not getting a MAC for satellite l during T is the probability of not receiving any of the MACs for this satellite transmitted through the different channels.
We can now calculate the probability of not decoding successfully any key usable to authenticate satellite l's MAC during T as follows:
퐶 N푀퐾 1 푖 퐾̅ = [ ∑ (퐾퐹퐸푅) ] (3.19) N푀퐾 푖=1
where N푀퐾 is the number of MAC-K sections in T, 퐾퐹퐸푅 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 can be explained with an example. Let us suppose that T is 30 seconds (1 subframe), and N푀퐾 is three, each MAC-K which one key. If satellite l's MAC was
93 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION received in the first MAC-K section, then it can be authenticated with any of the three keys that will come during T. The probability of not receiving successfully any valid key
3 nd is therefore (퐾퐹퐸푅) . If satellite l's MAC was received in the 2 MAC-K section, it is 2 (퐾퐹퐸푅) , and if it were in the first section, it is 퐾퐹퐸푅. As we do not know a priori to which section the MAC belongs, all sections are treated with the same probability 1/NMK , or 0.33. The sum of all cases is what Equation (3.19) provides.
In addition to the error rate in the MAC and the key, we need to account for the error rate in the navigation reception:
̅̅̅ 푁푙 = 푁퐹퐸푅푙 (3.20)
Where 푁퐹퐸푅푙 is the navigation frame error rate for satellite l. We are assume that it is transmitted once every T, and only from each satellite. Otherwise, a power factor would be applied as in case of the MAC and the key.
As mentioned before, we need correct navigation, key and MAC to successfully authenticate a satellite. Therefore, the probability of successfully authenticating satellite l is:
푆푙 = 푀푙퐾푁푙 = (1 − 푀̅̅̅̅푙)(1 − 퐾̅)(1 − ̅푁̅̅푙) (3.21)
To calculate the probability of authenticating four satellites, we can use the probability function of a binomial distribution.
푛 푝(푋 = 푘) = ( ) 푝푘푞푛−푘 (3.22) 푘 where 푝(푋 = 푘) is the probability that variable X gets k successes after n experiments, being 푝 the probability of success, and q the probability of failure. In our case, we need to compute (푋 ≤ 푘) where p is 푆̅ i.e. the probability of a failed satellite authentication, 푆̅ = 1 − 푆; and k = L – 4, L being the total number of satellites in view. We remove the sub-index l for simplicity, assuming the same probability for all satellites.
In other words, we compute the cumulative probability of these cases: no satellite failed (퐹 = 0), one satellite failed (퐹 = 1), two satellites failed, etc., until all-minus-four satellites failed. In all these cases, there is a data-authenticated PVT.
94
푝(퐴푈푇퐻푃푉푇) = 푝(퐹 ≤ 퐿 − 4) = (3.23) 푝(퐹 = 0) + 푝(퐹 = 1) + ⋯ + 푝(퐹 = 퐿 − 4)
Table 8 presents the NMA performance scenarios and associated parameters.
Table 8 – NMA Performance Scenarios and Parameters
Parameters vs. Nominal-2C Nominal-1C Worst Case Scenarios T 30s 30s 30s C 2 1 1 NMK 3 3 1 NM,l 1 1 1 Key Size 82 bits 82 bits 128 bits MAC & MAC Info 26 bits 26 bits 36 bits Size Navigation Size (NN) 506 bits 506 bits 506 bits
Here are some considerations about the scenario parameters:
T = 30 seconds implies one I/NAV subframe. C = 2, is considered a moderately pessimistic assumption, given that between 15 to 20 connected satellites can be expected (i.e. between half and 2/3 of a full 30- satellite constellation, provided a reasonable user visibility, system availability and system uplink plan). Anyway, the even more pessimistic case of C = 1 is also analysed. The nominal scenario is related to the 82-bit key, 10-bit MAC case with 3 MAC- K sections already presented. The worst-case scenario takes the longest keys and MACs (128 bits and 20 bits, respectively). The worst-case scenario implies that only one key is transmitted every 30 seconds. In this scenario, we assume 9 MACs are transmitted as well, which is a correct assumption taking into account the available bandwidth (floor((480 – 128)/36=9).
NM,l = 1 implies that, for each satellite in view, the system transmits its MAC at least once per channel every T. Given that there are 9 MACs per channel in all cases, and only the nearest neighbour satellites are transmitted, it seems a reasonable assumption that all satellites in view are nearest neighbours of the connected satellites (more details about the validity of this assumption in practice are given in section 3.8.1), and at least one MAC is received.
95 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
The following plots in Figure 33 present some results for different scenarios: Nominal- 2C (top), Nominal-1C (middle) and Worst-Case (bottom).
96
Figure 33 – Probability of successfully authenticating one satellite (S) (i.e. 1 – AER) when only the MAC & key is required (blue), and when the MAC & key & navigation is required (red), vs. the probability of successful reception of navigation information (black). Top: Nominal-2C Scenario; Middle: Nominal-1C Scenario; Bottom: Worst-Case Scenario Figure 33 above shows an interesting result: in the Nominal-2C scenario, adding the requirement to receive the MAC and key bits and authenticating a satellite does not decrease the probability of successful demodulation of navigation. If the navigation has been demodulated already, which may be often the case (let us recall that it is updated only every about one to 2 hours), the probability of authentication (S when 푁̅̅̅푙 = 0) is high. Even at very bad bit error rates, as 0.01, S remains around 90%. In the case of one channel, the degradation is still very low. In the worst-case scenario, an appreciable difference is observed between receiving navigation only and navigation + authentication, although the difference is not dramatic. For example, with a BER of 0.001, the probability of navigation reception is around 0.6, while it is 0.5 for navigation + authentication. We can also see that the probability of authentication only (S when
푁̅̅̅푙 = 0) is significantly degraded with respect to the standard case. E.g. at a BER of 0.001, the probability of authentication is 0.2 in the worst-case scenario and 0.85 in the Nominal-2C scenario.
In Figure 34 we characterise the performance of authenticated PVT with four or more satellites, as per Equation (3.23), for the three scenarios. The plots show that, in the Nominal-2C case, even at BERs as high as 0.01, if the receiver already has the navigation data, it will be able to compute a data-authenticated position, e.g. with a probability higher than 95% with 6 satellites in view. The plots show that, the more satellites in
97 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION view, the more likely to authenticate, as one could expect from (3.23). Another way to look at it is that if there are more satellites in view, even at the same number of channels, there are more combinations of receivable MACs leading to a successful data authentication.
98
Figure 34 – Probability of data authenticated position (PVT) vs. BER, for 4 to 9 satellites in view, based on S without navigation reception. Top: Nominal-2C Scenario; Middle: Nominal-1C Scenario; Bottom: Worst Case Scenario Figure 35 shows the authentication probabilities when the navigation has to be received as well. It shows that, due to the need to receive the navigation bits, the probability of data-authenticated PVT is highly degraded. The figure does not show the difference with the navigation-only (i.e. not authentication) probability, but we can infer from the previous results that it will be almost the same.
99 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 35 – Probability of data authenticated position (PVT) vs. BER, for 4 to 9 satellites in view, based on S including navigation reception. Top: Nominal-2C Scenario; Middle: Nominal-1C Scenario; Bottom: Worst Case Scenario The results show that adding the proposed data authentication scheme does not generally degrade the navigation availability performance. It may marginally reduce availability in some cases and, only in some extreme cases, it will have an impact in navigation performance.
3.9.2. Time To First Authenticated Fix
Time To First Authenticated Fix reflects the time a receiver takes to calculate a position fix based on at least four data-authenticated satellites. Table 9 presents TTFF (i.e. time to
100
first fix with no authentication, in standard conditions) versus TTFAF in different receiver start-up cases. The analysis considers that K-root can be received in 3 subframes, which seems a realistic, if not conservative, assumption in view of Figure 19. The definition of factory, cold, warm and hot start is based on [5] and extended for authentication. Table 9 shows that, except for a very specific case ("Cold Start, No K- root", which should not occur often, if it occurs at all), time to fix will not be degraded by adding authentication.
As TBA is 10s, and therefore much lower than the time to get a full subframe (30s), and taking into account the slight degradation in error rates, the difference between TTFF and TTFAF is negligible, except in two cases: when the receiver needs to receive the signed K-root at start-up, which is foreseen to occur very seldom; and when the receiver synchronization is so loose that it needs to process a 'slow MAC'.
101
Table 9 – Data Authentication in different Acquisition Modes
Almanacs K-root P0 T0 (<1 TOW Ephemerides Data- Comments and Assumptions TTFF; TTFAF (<100km min) & clocks authenticated error) Ephemerides
Factory Start N N N N N N N In this case, all K-root and MAC-K authentication information is received in parallel to the Almanac within the I/NAV TTFF = TTFAF≈ 15 min Frame (720s), so authentication does not degrade TTFAF wrt. TTFF.
Signal Acquisition lasts 2.5 min approx.
Cold Start, No K-root Y N N N N N N This case should not occur if a receiver is switched on regularly (e.g. once per week). TTFF ≈ 1 min Signal Acquisition lasts 30 seconds. TTFAF ≈ 2 min K-root received in 3 subframes.
Cold Start, K-root Y Y N N N N N In this case, all MAC-K authentication information is received within an I/NAV subframe, so authentication does not TTFAF = TTFF ≈ 1 min degrade TTFAF wrt. TTFF.
Warm Start Y Y Y Y N N N The receiver has an approximate position to reduce acquisition search space. No difference in data demodulation process TTFAF = TTFF ≈ 30 seconds wrt. cold start, K-root.
Hot Start Y Y Y Y Y Y Y The receiver navigates with the previously authenticated ephemeris. TTFAF = TTFF ≈ 1 second If anti-replay is considered, TBA (10 seconds) should be waited for a new authentication event.
102
3.9.3. Performance Assessment in Urban Environments – A Practical Case
The purpose of this section is to generally characterise the NMA performance of the proposed approach in low visibility conditions. The analysis uses a "simplified LMS (Land Mobile
Satellite)" model, in which, instead of simulating fading events, we add a C/N0 degradation and a masking angle to remove satellites from the visibility field9 on an AWGN channel. With the Galileo I/NAV convolutional encoding and interleaving, a BER as bad as 0.01 is obtained at a C/N0 between 23 and 24 dBHz (i.e. 20 dB below the standard 44-45 dBHz open- sky reception conditions). There may be differences between an AWGN channel and a LMS channel based on statistical models as the Jahn model [59]. However, this is compensated by the C/N0 reduction and masking proposed. The interleaving property of the I/NAV message makes data more resilient to temporary busts of corrupted bits due to fading as occurs in LMS channels. The masking angles are defined in Table 10.
Table 10 – Masking vs. Azimuth and elevation – Urban Environment
Zone Elevation range Azimuth range Signal Attenuation
A 0 - 5 Degrees 0 - 360 Degrees Masked
B 5 - 30 Degrees 210 - 330 Degrees Masked
C 5 - 30 Degrees 30 - 150 Degrees Masked
Background Area out of Zones A, B, C 0
9 Based on LMS model proposed by Thales Alenia Space France for the CESAR project (EC internal documentation).
103
SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 36 – Masking vs. azimuth and elevation sky plot - Urban Environment, using GNSS Planning Online tool [60]
Figure 36 shows the elevation and azimuth mask in a sky plot. The C/N0 is degraded as per Table 11:
Table 11 – C/N0 reduction vs. elevation
Environment Name Revised C/N0 C/N0 [dBHz] drop [dB]
el > 70° -16 28 dBHz
30° < el < 70° -17 27 dBHz
15° < el < 30° -19 25 dBHz
el < 15° -21 23 dBHz
In the original model, the degradation was 6, 7, 9 and 11 dB, i.e. 10 dB less. However, we already know that in the region of 30 dBHz or more, the Galileo I/NAV BER is low (at least with the currently used AWGN model) and error rates will be negligible, as shown in Figure
28. To worsen the conditions, the delta C/N0 has been reduced by 10 extra dB to what was originally proposed.
To select a representative case for Galileo FOC, the GPS constellation has used as a reference. Here are the parameters used for the analysis:
104
Position: 48.8567° N, 2.3508° E. The location of Paris has been selected for the analysis, as a city with average latitude and longitude within Europe, and therefore representative. GPS constellation has been selected as a reference. Out of the 31 operational satellites, satellite 'G06' has been taken out to match the number of 30 expected Galileo satellites (24 in operational slots plus 6 spares). The choice of satellite 'G06' is because at the time of this writing, its almanac is outdated and its orbit seems the furthest from nominal. Its RAAN is -67º, between the RAANs of -100º and -40º of the nominal orbital planes. Figure 37 shows the satellites visible over the 24-hour ground track period.
Figure 37 – Satellite view, 48.8567° N, 2.3508° E, 30 GPS satellites, 1/4/2015, using GNSS Planning Online tool [60]
We select an instant in which six satellites are in view with an average geometry (note that the geometry does not have a significant impact in the analysis but it affects the
C/N0, as it depends on the elevation).
Figure 38 – Sky plot at 1/4/2015, 10:20:00, using GNSS Planning Online tool [60]
105 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
3.9.4. Assumptions for satellites transmitting NMA
We assume around 2/3 and 4/5 of the 24 operational satellites (i.e. around ½ and a 2/3 of the full 30-satellite constellation) to be connected, i.e. between around 15 and 20 satellites connected. For our case, we assume three channels, i.e. three satellites are connected. We assume they are those at the worse elevations. We therefore consider satellite 2, satellite 7 and satellite 23 as connected. We can assume a C/N0 in good receiving conditions and including the noise added by the receiver to be 44 dBHz [5] (Ch.6, table 6.3). Their elevations and C/N0 according to the model are:
Table 12 – Revised C/N0 of satellites transmitting NMA
Elevation Revised C/N0 drop C/N0
Sat 2 33º -17 dB 27 dBHz
Sat 7 26º -19 dB 25 dBHz
Sat 23 53º -17 dB 27 dBHz
3.9.5. Assumptions for satellite MAC sequence
The assumptions for the MAC sequence transmitted in the MAC-K section are based on the proposal of 82-bit keys and 10-bit MACs. Every 30 seconds, 9 unique MACs per connected satellite are transmitted. The 9 MAC sequence includes:
8 MACs with ephemeris and clocks authentication for 8 satellites. These satellites will be the closest 8 in distance (including one constellation only). One MAC with ionospheric corrections 67% of the time, and a "slow MAC" the remaining 33%. Out of the satellites cross-authenticated, we assume that 50% are discarded as they belong to out-of-view satellites. We also assume that all satellites in view are always part of the 9 satellites authenticated per channel. These assumptions seem correct as demonstrated in section 3.8.1. We also assume that the connected satellites authenticate themselves but do not authenticate other connected satellites. The receiver is loosely synchronised to less than 10 seconds error to GST. Therefore, the 'slow MAC' is not needed. IonoBGD MACs are also ignored in the calculation assuming they are not needed.
106
Based on these assumptions, we fix the 30-s subframe sequence as per the Table 13.
Table 13 – MAC-K sequence from 3 connected satellites and packet error rates (err. Probabilities)
CN0 [dBHz] Sat 2 IonoBGD-1 S2-1 S10-1 K11 S4-2 K21 S13-2 K31 27 Error probabilities 9.432E-07 9.432E-07 2.975E-06 9.432E-07 2.975E-06 9.432E-07 2.975E-06 Sat 7 IonoBGD-2 S7-1 K12 S4-1 S13-1 K22 S10-3 K32 25 Error probabilities 2.188E-03 6.883E-03 2.188E-03 2.188E-03 6.883E-03 2.188E-03 6.883E-03 Sat 23 Slow MAC S23-1 S10-2 K13 S4-3 K23 S13-3 K33 27 Error probabilities 9.432E-07 9.432E-07 2.975E-06 9.432E-07 2.975E-06 9.432E-07 2.975E-06
Table 13 has been generated taking as inputs the packet (MAC, key) lengths, the C/N0, and the signal properties to calculate the BER. Based on that, Table 14 shows the probability of authentication of each transmitted MAC for each satellite.
Table 14 – Probability of authentication of each of the MACs for each satellite during a subframe
Satellites/MACs S2-1
S2 9.432E-07
S7-1
S7 2.188E-03
S23-1
S23 9.432E-07
S4-1 S4 -2 S4 -3
S4 2.188E-03 9.432E-07 9.432E-07
S13-1 S13-2 S13-3
S13 2.188E-03 9.432E-07 9.432E-07
S10-1 S10-2 S10-3
S10 9.432E-07 9.432E-07 2.188E-03
As mentioned, the proposed algorithm does not cross-authenticate connected satellites. Due to that, the MACs from connected satellites at low elevations are not repeated, making the authentication of low-elevation connected satellites difficult. Perhaps this algorithm should be revisited, allowing connected satellites to cross-authenticate other connected satellites.
In most cases, the driver for the MAC authentication probability is the MAC reception, and not the key reception. This is due to the single one-way chain concept. Even for MACs in the
107 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
last MAC-K section (e.g. S4-3, S13-3), the probability of not getting the key is the probability of not getting any key from the last MAC-K section, i.e. (2.975*10-6)2* 6.883*10- 3, i.e. around 6*10-14.
In any case, to prove that the Authentication Error Rate of 4 satellites is close to zero, assuming the navigation is already present, we can again take a pessimistic scenario and compute the 푝(퐴푈푇퐻푃푉푇) as per (3.28). Assuming that the failure probability for all satellites is the highest one, i.e. that of satellite 7 (0.002188, and which is due to an artificial bottleneck due to the algorithm proposed), 푝(퐴푈푇퐻푃푉푇) is a cumulative binomial distribution of (푋 ≤ 퐾), K = 2, N = 6 and p = 0.002188. The result is as low as 0.999999792, i.e. 1 – 2*107. Therefore, with 6 satellites in view and the worst three connected satellites, the probability of not getting authentication information for a four-satellite PVT is very low, which means that data authentication should be available in urban environments under the conditions here presented, or similar conditions.
3.10. Signal Unpredictability and Anti-Replay Protection
This section characterises in detail the signal unpredictability of the proposed solution mainly in terms of USR and MPT, and characterises the level of anti-replay protection offered.
Maximum Predictable Time depends on how the encoding and interleaving process of the Galileo I/NAV message encodes the unpredictable bits in symbols (some of which are predictable and some of which not) and spreads them across the transmitted message. It comes out that all of the unpredictable symbols of every 2-second word are transmitted in a period of 0.4 to 0.5 seconds, leaving the remaining 1.6 to 1.5 seconds fully predictable. As a reference, we take a MPT of 1.6 seconds.
This is based on the assumption that every 40-bit "Reserved 1" field contains unpredictable information. As every "Reserved 1" field contains 32 bits of a MAC-K section, and the longest predictable interval of a MAC-K section is the 16 bits of the MAC-info field, all the "Reserved 1" fields contain some unpredictable symbols.
Unpredictable Symbol Ratio is calculated under the assumption that all symbols are predictable except the MAC and the key bits, excluding some last bits of the key to avoid attacks whereby the last key bits are deduced and rebroadcast. The number of unpredictable symbols can be determined as follows:
108
(퐾푙푒푛 − 퐾푝푟푒푑 + 푁푀퐴퐶 푀퐴퐶푙푒푛)푁푀퐴퐶퐾 푈푆푅 = (3.24) 푁푆퐹 where 퐾푙푒푛 is the key length (82 bits), 퐾푝푟푒푑 is the number of last bits of the key considered predictable, 푁푀퐴퐶 is the number of MACs in a MAC-K section (3), 푀퐴퐶푙푒푛 is truncated
MAC length (10 bits), 푁푀퐴퐶퐾 is the number of MAC-K sections in a subframe (3 in our proposal) and 푁푆퐹 is the total number of symbols in a given time period in which the message structure is repeated (I/NAV subframe).
3.10.1. USR and Predictability of the Last Bits of the Key
When assessing USR, one has to take into account that some of the a-priori unpredictable bits may be guessed by an attacker, as explained below, and in that case those bits become predictable. This attack seems unlikely, as it would not affect the data authentication but would just give a little more freedom for performing a replay. However, it has to be taken into account to characterise the solution.
The bit unpredictability is based on the MAC and key sections. We can consider the full MAC bits unpredictable, as having knowledge of the first bits does not give any advantage for the last bits. However, this is not the case for the key bits.
Let us assume that a key n bits long is being transmitted. At a given time, the key has already transmitted n-j bits, and only j remain (the meaning of j here is not related to the identification of an authentication frame). We also know that between the transmission of each new unpredictable key symbol, an attacker can 'guess' the remaining symbols by performing a brute force attack, in which all possible combinations of the remaining bits are tested by performing the chain function F, until the correct one is found.
For example, when j is 3, assuming conservatively an average unpredictable symbol ratio of 1/24 ms (round(40/250)), an attacker would have 24 ms to test all the possible combinations (23 in this case) that yield the correct key, and would guess the remaining bits, making them predictable.
We can calculate a boundary on how many bits are considered predictable as follows:
We assume a time per iteration of the chain function F for the attacker. We assume a standard CPU multiplied by a coefficient expressing how more powerful the attacker's
109 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
CPU will be, which depends on how many resources an attacker will devote for this attack. We must recall that the asset to protect is just the unpredictability of a few symbols. We define a tolerable probability of success of the attack. We evaluate when the total time for achieving the tolerable success probability exceeds the time between unpredictable symbols.
The equations below express the previous bullets in mathematical terms:
푗 휏푗 = 2 휏푖푡푒푟푃푠푢푐푐푒푠푠 (3.25)
휏푗 > 휏퐵푈푆 (3.26) where 휏푗 is the time an attacker will require to guess the remaining j bits of the key with a probability of success 푃푠푢푐푐푒푠푠, provided that it takes 휏푖푡푒푟 in one iteration. 푃푠푢푐푐푒푠푠 captures the fact that, if the system wants to protect against attacks with a 100% success rate, then attackers will need to test all combinations. If attacks testing fewer combinations and therefore giving a lower success rate, are considered still harmful, then 휏푗 will be shorter.
휏퐵푈푆 expresses the time between unpredictable symbols, so we should discard the bits that allow combinations solvable before the next symbol, i.e. before 휏퐵푈푆. Figure 39 compares
휏푖푡푒푟 with 휏퐵푈푆, assuming:
0.01 microseconds per SHA byte iteration (i.e. around 50-100 times faster than a standard current processor) A 10% maximum tolerable probability of success. An average of one unpredictable symbol out of 6 (i.e. 24 milliseconds time for an attacker to perform the attack).
110
Figure 39 – Time to compute the remaining bits of a key (휏푗) compared to the time between unpredictable symbols (휏퐵푈푆) Under these assumptions, it seems prudent to consider a value of j of 20 bits. That means that we will not consider the last 20 bits unpredictable for computing the USR. In the following sections, the number of predictable bits of the key will be defined as Kpred.
Applying Equation (3.24), that gives a total of 276 unpredictable symbols per subframe out of a total of 7500 symbols , i.e. an USR of 3.68%.That means that, in average, there are 9.2 symbols per second that are unpredictable, from which an anti-replay test statistic could be derived. In reality, and according to the Galileo I/NAV convolutional coding and interleaving scheme, all unpredictable symbols are concentrated every other second.
3.10.2. Symbol Unpredictability and MPT after Encoding and Interleaving
As shown in Figure 16, NMA is embedded in the "Reserved 1" field of each I/NAV word. As we want to increase signal unpredictability to protect against replay attacks, we have to analyse how 40 unpredictable bits are encoded into 80 unpredictable and predictable symbols. It is necessary to determine which symbols are considered unpredictable, and which not, and how the encoding and interleaving affects USR and MPT. One can anticipate that the entropy of the signal will not be increased by coding, i.e. that if there are 40 unpredictable bits, which are coded into 80 symbols, only 40 of them will be unpredictable. However, in order to understand their place in the symbol stream, a deeper analysis is performed in this section.
Galileo signals, and in particular the I/NAV message, are convolutionally encoded with the following data coding parameters [12]:
Coding rate: ½
111 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Coding scheme: convolutional
Constraint length: 7
Generator Polynomials (in octal10): G1=171o ; G2 = 133o
Encoding sequence: G1, then G2.
Each bit is encoded into two symbols (i.e. coded bits), which depend on the present and past bits according to the scheme in Figure 40. Further details on convolutional coding and interleaving can be found in [61], particularly in Ch.8, S. 8.8.2.
Figure 40 – Galileo I/NAV convolutional encoding [12] In addition to the encoding, the symbols are interleaved to add robustness against temporary fading effects in the channel. Galileo I/NAV interleaving consists of a block interleaver of size 240, i.e. all the symbols in an I/NAV word except the synchronisation sequence, and dimensions of 30 columns x 8 rows. That means that the 240 symbols are written, column after column, in 30 columns of 8 symbols each, and read row by row, so the symbols are scattered across the 240-symbol packet. To decode the bits from the symbols, most receivers use a Viterbi decoder [62].
The 40 "Reserved 1" bits are those located between bit 19 and bit 58, both included. This means that symbols 37 to symbol 128, both included, contain "Reserved 1" bits.
Each new unpredictable bit will lead to two new symbols. If the symbols were not interleaved, the first (from G1) would be unpredictable, and the second (from G2) would not. The 240-bit stream will look as in Table 15 in the interleaver:
Table 15 – I/NAV 240-symbol unpredictability before interleaving. Green: unpredictable symbols. Yellow: predictable symbols based on unpredictable bits. White: predictable symbols based on predictable bits
10 For example, 171o = 1111001 in binary.
112
1 9 17 25 33 41 49 57 65 73 81 89 97 105 113 121 129 137 145 153 161 169 177 185 193 201 209 217 225 233 2 10 18 26 34 42 50 58 66 74 82 90 98 106 114 122 130 138 146 154 162 170 178 186 194 202 210 218 226 234 3 11 19 27 35 43 51 59 67 75 83 91 99 107 115 123 131 139 147 155 163 171 179 187 195 203 211 219 227 235 4 12 20 28 36 44 52 60 68 76 84 92 100 108 116 124 132 140 148 156 164 172 180 188 196 204 212 220 228 236 5 13 21 29 37 45 53 61 69 77 85 93 101 109 117 125 133 141 149 157 165 173 181 189 197 205 213 221 229 237 6 14 22 30 38 46 54 62 70 78 86 94 102 110 118 126 134 142 150 158 166 174 182 190 198 206 214 222 230 238 7 15 23 31 39 47 55 63 71 79 87 95 103 111 119 127 135 143 151 159 167 175 183 191 199 207 215 223 231 239 8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128 136 144 152 160 168 176 184 192 200 208 216 224 232 240
After the interleaver, the sequential dependency between unpredictable symbols and bits is broken, so it is not a priori obvious which symbols based on unpredictable bits, are indeed unpredictable, and which not. However, if a receiver wants to perform a test statistic based on the unpredictable symbols to protect against replay attacks, it must know which symbols are considered unpredictable. The post-interleaving symbol unpredictability has been determined as follows:
The unpredictable bits are considered as unknowns. Every time a new symbol is received, which depends on one or several unpredictable bits, a new equation is added to a system. This equation adds the new unpredictable bits as new unknowns. When the number of equations equals the number of unknowns (i.e. when the number of already received unpredictable symbols equals the number of unpredictable bits involved in those symbols), the system can be solved. If all the unpredictable bits are in the system, then the stream will not be predictable anymore.
Table 16 – I/NAV 240-symbol unpredictability before interleaving considering 8 H-K-root bits predictable.
1 9 17 25 33 41 49 57 65 73 81 89 97 105 113 121 129 137 145 153 161 169 177 185 193 201 209 217 225 233 2 10 18 26 34 42 50 58 66 74 82 90 98 106 114 122 130 138 146 154 162 170 178 186 194 202 210 218 226 234 3 11 19 27 35 43 51 59 67 75 83 91 99 107 115 123 131 139 147 155 163 171 179 187 195 203 211 219 227 235 4 12 20 28 36 44 52 60 68 76 84 92 100 108 116 124 132 140 148 156 164 172 180 188 196 204 212 220 228 236 5 13 21 29 37 45 53 61 69 77 85 93 101 109 117 125 133 141 149 157 165 173 181 189 197 205 213 221 229 237 6 14 22 30 38 46 54 62 70 78 86 94 102 110 118 126 134 142 150 158 166 174 182 190 198 206 214 222 230 238 7 15 23 31 39 47 55 63 71 79 87 95 103 111 119 127 135 143 151 159 167 175 183 191 199 207 215 223 231 239 8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128 136 144 152 160 168 176 184 192 200 208 216 224 232 240
The results of the algorithm are presented in the capture below (Table 17), for the case in which the last 32 out of the 40 "Reserved 1" bits are considered unpredictable, consistently with the current proposal, in which the first 8 bits are devoted to the H-K-root section and are considered predictable. That means that the first unpredictable symbol is the 8th one (57) and not the 6th one (41), as shown in Table 16.
113 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Table 17 – Results of unpredictability analysis after I/NAV convolutional encoding and interleaving
Symbol Position | Nb. Equations | Nb. Unknowns | 2^(U-E) 8 1 3 4 9 2 7 32 10 3 11 256 11 4 15 2048 12 5 19 16384 13 6 23 131072 14 7 27 1048576 15 8 31 8388608 16 9 32 8388608 38 10 32 4194304 39 11 32 2097152 40 12 32 1048576 41 13 32 524288 42 14 32 262144 43 15 32 131072 44 16 32 65536 45 17 32 32768 46 18 32 16384 68 19 32 8192 69 20 32 4096 70 21 32 2048 71 22 32 1024 72 23 32 512 73 24 32 256 74 25 32 128 75 26 32 64 76 27 32 32 98 28 32 16 99 29 32 8 100 30 32 4 101 31 32 2 102 32 32 1 ** MAXIMUM PREDICTABLE TIME [ms]:1620 ** UNPREDICTABLE SYMBOL RATIO (Ubps):32/(250+250)=0.065306
The first column shows the position of unpredictable symbols, which can be used by the receiver to protect against replay attacks. Then the results present the total number of equations every time a new unpredictable symbol (equation) is found. The next column is the number of unknowns (unpredictable bits depending on received symbols), and the last column presents the minimum number of possibilities that an attacker should search.
The results also present the maximum predictable time at the bottom, i.e. the time between the last unpredictable symbol of an I/NAV word, and the first of the next word. The algorithm also presents the number of possibilities (2^(unknowns – equations)), to assess the risk that a spoofer would 'guess' the unpredictable symbols. We see that, for most of the unpredictable symbols, the number of possibilities is very high. Therefore, it is not considered worth to discard any unpredictable symbol from the test statistic. The MPT result is 1.620 seconds.
We can see that, after the symbol in position 102, the system of equations can be solved, and the remaining symbols are predictable. The results of the analysis showing the positions of unpredictable symbols are presented in Table 18.
114
Table 18 – I/NAV 240-symbol unpredictability after interleaving.
1 9 17 25 33 41 49 57 65 73 81 89 97 105 113 121 129 137 145 153 161 169 177 185 193 201 209 217 225 233 2 10 18 26 34 42 50 58 66 74 82 90 98 106 114 122 130 138 146 154 162 170 178 186 194 202 210 218 226 234 3 11 19 27 35 43 51 59 67 75 83 91 99 107 115 123 131 139 147 155 163 171 179 187 195 203 211 219 227 235 4 12 20 28 36 44 52 60 68 76 84 92 100 108 116 124 132 140 148 156 164 172 180 188 196 204 212 220 228 236 5 13 21 29 37 45 53 61 69 77 85 93 101 109 117 125 133 141 149 157 165 173 181 189 197 205 213 221 229 237 6 14 22 30 38 46 54 62 70 78 86 94 102 110 118 126 134 142 150 158 166 174 182 190 198 206 214 222 230 238 7 15 23 31 39 47 55 63 71 79 87 95 103 111 119 127 135 143 151 159 167 175 183 191 199 207 215 223 231 239 8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128 136 144 152 160 168 176 184 192 200 208 216 224 232 240
We can therefore conclude that convolutional encoding and interleaving maintains the entropy and unpredictability of the signal in a way that can be determined a priori by the receiver, depending on the message structure. We have also demonstrated that, out of n unpredictable bits coded into 2n symbols, the first n symbols based on unpredictable bits after interleaving can be considered unpredictable.
3.10.3. Detection of Signal Replay Attacks Based on NMA
So far, the anti-replay capabilities of the solution have been characterised from a system perspective, i.e. by how often, and how much, the signal will be unpredictable. To provide a benchmark of how this unpredictability is translated into protection against replay, this section analyses the replay detection performance based on NMA unpredictable symbols.
A full characterisation of security code estimation and replay (SCER) attack detectors using different test statistics is presented in [25]. This section proposes some theoretical analyses to validate the assumption that NMA unpredictability does protect against signal replay. It also presents some general characterisation of the detection process. The replay attack analysed here consists of a zero-delay attack, as described in [25]. In this attack, the spoofer estimates and rebroadcasts the symbols at the same time (or with a minimal delay) as the receiver in order to initially take control of the tracking looks and then to start gradually adding a delay to the pseudorange. Before the attack, we assume that the receiver is locked to authentic signals.
A non-zero delay attack requires the attacker to force signal reacquisition by jamming the receiver for some seconds (e.g. 20 seconds for a two μs delay with a static receiver using a 0.1-ppm TCXO (Temperature-Controlled Cristal Oscillator), as per [25]). The fact that the receiver may have other means to detect this attack is left out of the scope of this section.
Within the zero-delay attack, we assume that the attacker is continuously transmitting a signal with a zero delay (or a delay that is so close to zero that does not represent any
115 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION difference in the symbol detection process). We assume that the attacker is not switching on and off the spoofer so that at the beginning of an unpredictable symbol is off, and it is on otherwise, as this could be detected by e.g. looking at signal power variation patterns.
This section proposes a replay detection method based on the accumulation of the first signal samples of each unpredictable symbol, and the correlation of that signal sample sequence with the known replica once the symbols are authenticated. The purpose of the proposed method is just to demonstrate the protection against replay provided by unpredictable symbols. Other methods optimised for different receiver types are possible.
In order to detect if the signal is correct, the receiver can accumulate the first samples of the
NC chips of NU unpredictable ±1 symbols over a given interval. The receiver will accumulate the samples of NCNU chips. In our NMA study case, in a time interval of 30 seconds each usable satellite transmits 276 unpredictable symbols (NU = 276). Once the NU symbols are received and authenticated, the receiver can generate a replica of the NCNU sequence and correlate it with the received signal samples. By this process, the power gain 퐺푎 obtained from an authentic signal can be approximated by the total number of chips correlated [63], or
푁퐶푁푈.
퐺푎 = 푁퐶푁푈 (3.27)
For example, if NU = 276 and we use the first 5 chips of each unpredictable symbol (푁퐶 = 5), the gain would be 퐺푎 = 1380, or 31.39 dB.
One potential disadvantage of this method is that it cannot take advantage of the cross- correlation properties of PRN codes, which minimise the interference between satellites, as only the first chips are looked at. Therefore, one can expect a higher level of interference due to other satellites for both authentic and spoofed signals. In any case, for the rest of this section, we assume that the 푁퐶푁푈 sequence is long enough to have a significant gain above the noise plus interference level. We will also assume that a processing gain in that order will be sufficient, even noting that the pre-correlation SNR of a typical receiver can be in the order -20 dB, as shown in [5], Ch. 6, and therefore a power gain of 30dB or more is desirable.
This assumption depends on the number of unpredictable symbols used, but assuming 푁푈 is high enough, the conclusions are considered valid. This is why the USR is one of the key NMA design performance indicators.
116
If the receiver is tracking a spoofed signal subject to a zero-delay attack, the gain will be much lower, and will depend on the probability of successfully estimating the symbol by the spoofer with a much-reduced number of samples. For every set of m samples, we can calculate the probability of error in the estimation of an unpredictable symbol by the spoofer as follows:
1 푝 (푚) = 푒푟푓푐(√푚푇푠퐶/(푁 + 퐼 ) ) (3.28) 푒푟푟 2 0 0 where m is the number of samples integrated by the spoofer, 푇푠 is the sampling period and
퐶/(푁0 + 퐼0), 푠 is the carrier to noise plus interference density ratio as seen by the spoofer. Note that 푚푇푠 is a measure of time, and is equivalent to 푁푐푇푐 being 푇푐 the chip period. Figure 41 shows the error probability in the estimation of a symbol after 푚푇푠 microseconds of integration, for four different spoofers, each one receiving the signal at different 퐶/(푁0 + 퐼0) of 42 dBHz, 45 dBHz, 48 dBHz and 52 dBHz.
Figure 41 – Probability of error in the estimation of an unpredictable symbol wrt. Integration time (M*Ts), for different C/(N0 + I0) values
As mentioned before, the 퐼0 term a priori cannot be neglected for a few samples, as cross- interference from other satellites may be neglected after correlation with a full code, but this is not the case if only a few samples are taken. Due to the 퐼0 term, carrier to noise values can be lower than the standard C/N0 of around 45 dBHz. However, as the spoofer may incorporate additional hardware to raise the signal power, as directional antennas, higher
117 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
values are considered. The importance of the 퐼0 term is not so relevant as we analyse in relative terms the difference between the spoofed and non-spoofed cases.
It should be noted that 푝푒푟푟 is the error probability after 푚푇푠 integration. The average probability of error of the total M samples is higher, and will be between 0.5 and 푝푒푟푟. We call this average Unpredictable Symbol Error Rate (USER):
푀 1 푈푆퐸푅 = ∑ 푝 (푚) (3.29) 푀 푒푟푟 푚=1 where M is the total number of samples integrated per unpredictable symbol (푀 = 푁푐푇푐/푇푠). Assuming that the receiver performs the abovementioned correlation over a spoofed signal, the power gain when tracking a spoofed signal would be limited as follows:
2 2 퐺푠 = 푁퐶(1 − 2 푈푆퐸푅 ) 푁푈 = 퐺푎 (1 − 2 푈푆퐸푅 ) (3.30)
The factor 2 multiplying USER is due to the fact that the wrongly guessed symbols not only do not add, but subtract from the correlation peak. It assumes that the spoofer does not stop transmitting even from the beginning of the symbol. If this case is considered pessimistic for the spoofer, we can consider USER = 푝푒푟푟(푀). Figure 42 shows the reduction in the gain between G,s and G,r for different integration times, for spoofers at a C/(N0 + I0) of 42, 45, 48 and 52 dBHz under the case USER = 푝푒푟푟(푀).
118
Figure 42 – Minimum Gain Reduction when spoofed (Maximum spoofed vs non-spoofed gain), vs. Integration Time (M*Ts) The gain reduction is quite evident especially if only the beginning of unpredictable symbols is taken. Following the above example, if we use look at the first 5 chips (5 μs approx.) of each unpredictable symbol, and we correlated spoofed signals for a 45 dBHz spoofer, our gain would be reduced by more than 7 dB with respect to tracking an authentic signal.
We must note that a low gain may be due to a degradation in the original signal, in which case not only 퐺푎 would be reduced, but also other standard signal indicators as C/N0 and bit error rate, leading possibly to an authentication denial of service, but not to an authenticated position with signal under delay attack.
3.10.3.1 USR Impact in detection of Signal Replay Attacks
A receiver needs two inputs to perform this antireplay test:
The validation of the unpredictable symbols. This occurs every TBA seconds (TBA=10, 20 or 30s, depending on the implementation). The accumulation of a high enough amount of chips from unpredictable symbols to
generate a peak above the noise and interference. This depends on NC and NU, which in turn depends on USR.
119 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
As mentioned above, NU = 276. Depending on the amount of unpredictable symbols, the receiver can wait for more time or less time. Waiting for less time to compute antireplay statistics makes the system more robust. On the other hand, raising Nc also facilitates the success rate of the spoofer. Sensitivity analyses and trade-offs on this respect are left further work beyond this thesis. Even if we have to wait for 30 seconds to get enough symbols, the receiver could perform the check every 10 seconds (TBA), by sliding a 30-second window every 10 seconds. What seems clear is that symbol unpredictability is a relevant KPI if NMA is designed to be used against replay attacks. While more detailed analyses and metrics can be performed, including hypothesis testing versus missed detection and false alarm probabilities as those proposed in [25] and outlined in [39] and [36], we can conclude that adding unpredictability to the signals highly restricts the possibilities of a spoofer to perform replay attacks.
3.11. Conclusions
This chapter has presented the main motivations to study the provision of an open navigation message authentication (NMA) service. Out of the key performance indicators defined to characterised NMA solutions, TBA and AER stand out as the most important. USR and MPT are also relevant if the NMA solution is meant to protect against replay attacks.
A TESLA protocol seems more convenient than digital signatures for NMA due to the lower amount of data required per authentication. TESLA protocols using a single chain of keys for all satellites are very advantageous as they reduce the authentication data required even further. Reducing authentication data also reduces AER and TBA, improving the overall NMA performance. To improve NMA availability in difficult visibility conditions and overcome mitigations in the authentication transmission, some satellites can transmit MACs to authenticate neighbouring satellites.
A concrete NMA proposal including these concepts is proposed in the Galileo E1-B I/NAV message structure using the "Reserved 1" field, which provides 20 bps. The NMA structure proposed is divided in two main sections: The H-K-root section to transmit a header and a signed root key (4 bps), and the MAC-K sections to transmit the MACs and keys used regularly for authentication (16 bps). A NMA implementation proposal considered secure at the time being consists of one MAC-K section every 10 seconds, containing three MAC sections of 26 bits, including 10-bit MACs, and an 82-bit key. Anyhow, the concept follows a
120
flexible approach whereby the SIS can inform the receiver about the MAC and key sizes for new chains, allowing keeping high system robustness during the system lifetime even in case of computational and cryptanalysis progresses.
The proposed solution is then characterised, mainly in terms of TBA and AER. A TBA of 10 seconds provides a very low time to first authenticated fix and a high robustness, while maintaining a sufficient cryptographic security level at the time being. TBA can be reduced to 5 seconds in average at user level by adding a transmission offset to a subset of satellites. AER is very low as well, thanks to the low number of bits required for authentication and the possibility to get most of them from the best visible satellite(s), maximizing the availability of the authentication service even in degraded conditions. MPT achieved is in the order of 1.5 seconds, and USR yields 276 unpredictable symbols every 30 seconds, even considering the last 20 bits of a key as predictable. USR can be improved by encrypting each MAC-Info section with the key delivered later.
The NMA performance in degraded environments is characterised, showing that availability is just minimally degraded or not degraded at all, when navigation data is authenticated, with respect to standard non-authenticated navigation.
The chapter also discusses the value of NMA against replay attacks. A method is proposed in which, by storing the first chips of every unpredictable symbol, a receiver can create a signal sequence whose correlation gain will be very low once if the signal is spoofed. This justifies why signal unpredictability is a relevant design parameter and is maximised in the proposal.
As a summary, Table 19 presents the performance of the proposed NMA solution.
Table 19 - Performance characterization of the proposed authentication solution
Indicator Result Comments
Availability No degradation Same performance as standard navigation with Galileo I/NAV
Accuracy No degradation Same performance as standard navigation with Galileo I/NAV
TTFAF No degradation Except in "cold start, no K-root" or "slow MAC"
121 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
cases
TBA 10 sec
MPT ~1.6 sec Every 2 seconds, 40 authentication bits out of which some are unpredictable, are transmitted.
USR 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 30, Minimal degradation wrt. navigation frame error Figure 31 rates.
Based on the design choices and the experimentation results, we can conclude that the proposed NMA solution is compliant with the user needs listed in Table 1 at the beginning of the chapter.
122
Chapter 4. Snapshot Positioning Without Initial Information
4.1. Motivation
Thanks mainly to GPS, satellite navigation technologies have become ubiquitous. Currently they are used in various devices and applications such as smartphones, personal navigation devices, vehicle guidance, machine control, and many others. Future devices may include miniaturised positioning 'dots' or stickers attached to living beings or objects that are switched on sporadically at a given event or on request. For these applications, instantaneous, push-to-fix, or snapshot techniques are more suitable than standard receiver architectures.
Snapshot positioning techniques are based on saving digital samples from the ADC (Analog to Digital Converter) of a GNSS receiver front end, and post-processing them to calculate a position and time solution. When applied to standard GPS L1 C/A signals, the receiver can obtain frequency and pseudorange measurements from the signal processing block, and can use satellite ephemeris data coming from another source, e.g. a server or a pre-calculated set of long term ephemerides, to calculate a position solution. In this case, the receiver needs to calculate the full pseudorange measurements from the code phase measurements obtained from the acquisition or tracking stages, which are ambiguous, as snapshot techniques do not foresee the receiver to wait until a synchronization sequence (as e.g. TLM/HOW fields for GPS) is received.
To solve this ambiguity, the receiver can use an initial position from a server, which must be accurate to around 100 km if GPS L1 C/A codes are used, or it can calculate its initial position based on Doppler measurements as proposed in [5]. If the time is unknown, it can use the coarse time navigation equations [64]. However, it requires an initial time reference accurate to the level of a minute.
123 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
The purpose of this chapter is to present an algorithm based on snapshot positioning techniques that allows computing a position and time solution without any initial position or timing information.
Apart from potential applications as animal trackers, container trackers and the like, a main motivation for this work is to help solve the theoretical problem of how to calculate a position with as minimum information as possible.
4.2. Background
Standard standalone GPS receivers estimate the time of arrival of signals transmitted from satellites, and compute the satellite position from the signal data. They first acquire the signals, measuring its frequency (Doppler) and delay (code phase), by correlating a signal replica with the received signal. After acquisition, a receiver locks to the signals with dedicated tracking loops, and starts demodulating the data contained therein. As the receiver has a priori no synchronisation with the signal, it has to demodulate the signal data until a certain pattern is found (called TLM, or telemetry, in the GPS signal). After this pattern is found, the receiver can synchronise and start interpreting the data. This first includes the satellite time reference called in GPS Time of Week and Week Number (TOW and WN), and then the satellite ephemeris, which allow to compute the satellite position and clock offset. Once data is demodulated and time-of-arrival is estimated for at least four satellites, the receiver is able to compute a 3D position and its time offset. While the satellites are accurately synchronised to a time reference, the receiver is a priori not. This whole process may take between 30 seconds and 1 minute for standard receivers, until a first position fix is obtained.
The standard receiver acquisition process is described in detail by F. van Diggelen in [5] and K. Borre et al. in [13]. Classic receiver architectures involving acquisition and tracking stages are described by A. J. Van Dierendonck in Chapter 8 of [3] and by P. Misra and P. Enge in Chapters 11 and 12 of [2].
4.2.1. Snapshot Positioning
Snapshot positioning is based on the following steps:
Reception and digitalisation by the ADC of IF (Intermediate Frequency) samples of the target band, in which the positioning signals are foreseen.
124
Storage of a slice of raw digital samples of certain duration, in the order of some milliseconds, depending on the integration time and other considerations. Post-processing of the raw digital samples from which the frequency and code phase measurements are obtained. Estimation of the position and time of the receiver based on the measurements and satellite (and potentially propagation error) data.
Snapshot techniques provide some advantages over standard acquisition and tracking positioning:
They can provide an instantaneous position fix. They require much less power consumption, as the signals do not need to be tracked continuously. The receiving device can be cheaper than an ordinary GNSS receiver.
There are not many references in the open literature specifically about snapshot processing techniques. One of the earliest references focusing on snapshot techniques is [65], which presents some simulated performance of a high-sensitivity snapshot GPS software receiver. [66] describes a GPS/Galileo snapshot receiver and the signal detection theory behind, showing some simulated performance. [67] implements snapshot techniques based on coarse time navigation and presents some performance results. As a major building block of assisted GNSS, [5] describes snapshot techniques at signal processing level, and at PVT computation level. These techniques are based on the existence of a communication channel between the receiver and a server, which allows the server to compute the receiver position or to transmit to the receiver the satellite ephemeris to allow a faster, sometimes instantaneous, fix. Assisted techniques, as implemented in mobile phones or smartphones, are generally based on the synchronisation of the receiver through a wireless network, down to at least a few seconds. They also transmit a position and time reference to facilitate the acquisition process. Assistance techniques can therefore provide an instantaneous positioning and timing service. However, they generally require an initial position and time reference to function. To calculate the initial position, [5] describes in Ch. 8 the instantaneous Doppler algorithm, and how it can be combined with code phase, or pseudorange, measurements, for positioning. Doppler measurements are used to compute an initial position, accurate to some kilometres, which can be later used as a reference for a more accurate position using pseudorange measurements through the Coarse Time Navigation equations. However, this initial position
125 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION calculation requires a given initial time to be calculated, which has to be accurate to the level of minutes. [5] and [68] also presents methods to solve the time uncertainty by solving the navigation equations for each possible case, with an iteration at least every minute, and determining the correct solution by estimating the solution residuals. The required number of operations of this method implies that it cannot instantaneously determine a position and time solution with currently standard processing power if the initial time uncertainty is up to several days and without an initial position.
4.2.2. Snapshot Signal Acquisition and Measurement Accuracy
One of the potential limitations of snapshot positioning is the accuracy that can be obtained with the frequency and code phase estimations from the acquisition stage. The acquisition is generally performed in code phase and frequency bins. Parallel acquisition based on FFT (Fast Fourier Transform), as described in [13], allows speeding up the acquisition process and achieving a finer estimation of the delay-frequency acquisition peak. If a serial acquisition is followed with typical 500 Hz frequency bins, the maximum frequency error will be 250 Hz, (i.e. the case between two bins), with an mean error of 125 Hz (i.e. ¼ of the frequency bin, assuming a uniform error probability distribution between 0 Hz and 250 Hz). If the Doppler measurements are used for positioning, as is the case here, and given that a 1 Hz accuracy error can lead to approximately 1 km in the instantaneous Doppler positioning error [5], frequency estimation must be fine-tuned to obtain an accurate Doppler measurement. If serial acquisition is followed, the average delay error will be again ¼ of the correlator spacing, i.e. around 37.5m if the typical 0.5 chip correlator spacing is used.
Here are some methods proposed to improve accuracy of snapshot techniques.
Closed-Loop architectures: Once the signals are acquired, the receiver can run some standard tracking loops to do some fine adjustments of the phase, frequency and code, through PLL/FLL and DLL engines. Parallel FFT search: by performing FFT and IFFT (Inverse FFT) of the signals, a higher resolution than through serial bin search can be achieved. This is further explained later in this chapter, in the experimental results section. Interpolation in Open-Loop architectures: the receiver can take the correlation peak and the previous and next samples and fit the points to a function (either a triangle or
126
a parabola), and link the peak to the maximum of the function. This is further explained later in this chapter, in the experimental results section.
Another relevant aspect of measurement accuracy in open-loop architectures is the coefficient between the sampling frequency (fs) and the code frequency (fc). If fs is a multiple of fc, the correlation peak will be staircase-shaped and will limit the average accuracy of the pseudorange by the sampling rate (Ts = 1/fs). This matter is further explained in section 5.5.
4.2.3. Snapshot Synchronisation
If the raw signal samples are synchronised to the level of the spreading code duration (1 ms for GPS L1 C/A, 4 ms for Galileo E1B/C), the receiver can solve the code phase ambiguity and calculate the pseudorange from the code phase measurement. This is called fine time acquisition in [5] and can be achieved in U.S.'s CDMA mobile networks.
If the raw signal samples are synchronised just to the level of some seconds, then coarse time acquisition techniques apply. The time uncertainty in coarse time navigation can be solved by the coarse time navigation algorithm by Peterson et. al. initially presented in [64]. This algorithm allows a fix even if time is only known with a minute of error and hence satellite positions are not known, by adding a 5th unknown named "coarse time" to the navigation equations. The coarse time navigation algorithm is based on the solution of the following equation:
훿푥 훿푦
훿휌 = 퐻훿푋 + 휀 = [−푒푖 1 푅푅푖] 훿푧 + 휀 (4.1) 훿푏 [훿푡푐] where 훿휌 is the update of the a-priori state, i.e. a column matrix with the difference between the predicted pseudoranges 휌̂ and the measured pseudoranges 휌 (훿휌 = 휌 − 휌̂ ); H is the observation matrix that relates the measurements with the state vector 훿푋, −푒푖 is the estimated receiver-to-satellite-i unit vector with the opposite sign, RRi is the range rate of satellite i, and [δx δy δz δb δtc]T is the update of the state vector 훿푋, or the vector of unknowns to solve, which includes the receiver position (x, y, z), the receiver bias b, and the coarse time difference tc, i.e. the difference between the estimated measurement time and the actual measurement time. The measurement and linearization errors are represented by 휀.
127 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
The proposed system of equations resembles to that of standard PVT estimation one as described in [5], Section 4.2, or [2], Chapter 6, with the exception that it adds an unknown to the state vector, tc, to account for the coarse synchronisation time error.
Coarse time navigation is limited by a time uncertainty of around one minute. To reduce timing requirements, [68] proposes a method to calculate a fix by using Doppler and code phase measurements where the required time accuracy for the Doppler measurements (T0) can be relaxed to a maximum of twelve hours. While this method is targeting the same challenge as this chapter, it uses the Doppler instantaneous positioning method as described in [5] at different initial time solutions which differ in one minute. The method requires about 30 seconds processing in a standard processor to solve a 12-hour ambiguity.
4.2.4. Code Phase Ambiguity Resolution
As mentioned before, to calculate a position from the snapshot, the receiver needs to solve the code phase ambiguity. In order to solve the code phase ambiguity, the receiver needs to assign an integer number of codes Ni to the differential code phase of each satellite i. Due to the receiver clock bias, which commonly affects all code phase measurements, even if the receiver position, and satellite position at a time are roughly known, the receiver cannot know for sure what is the Ni of each satellite until it verifies the residuals of a solution. A method to calculate the integer codes is proposed in [5], Chapter 4. The method is previously described in [69]. It is mainly based on these steps:
Assigning a Ni to each satellite. For this, a satellite 0 is taken as a reference, its integer
code ambiguity N0 is estimated, and the Ni for the remaining satellites are estimated coherently. Solving the coarse time navigation equation with the estimated full pseudoranges. If the solution residuals are low (i.e. do not have an error of several km), then the
estimation is good. If not, another Ni combination is used.
In order to solve the code phase ambiguity, an initial position accurate to some km is required. The GPS code duration is 1ms, or 300 km at light speed, so to ensure that the right
Ni are taken, the position error should be less than 100km (and the time error less than a minute, as mentioned before).
128
Receivers connected to a communication network may easily obtain such an initial position. In other cases, instantaneous Doppler positioning can be used to provide an initial position. For a static or slow-moving receiver, the instantaneous Doppler equations are11:
훿푥 훿푦 훿퐷 = [ ′푖 ] [ ] + 휀 (4.2) −푒 1 훿푧 훿푓푑 where 훿퐷 is the update of the a-priori state, i.e. a column vector with the difference between the predicted Dopplers ̂퐷 and the measured dopplers D (훿퐷 = 퐷 − 퐷̂), −푒′푖 is the derivative in time of −푒푖, and [δx δy δz δfd]T is the update of the state vector, which estimates the receiver position and the frequency drift.
The Doppler measurements are obtained as the difference between the intermediate frequency at which the signals are down-converted in the receiver front-end, and the frequency measured from the acquisition engine. They can be also obtained as the difference between two pseudoranges taken at different epochs (dividing by the time increment), or two carrier phase measurements from the tracking loops. We must note that Doppler and range rate have inverse signs, i.e. when the satellite is approaching (the range is diminishing), the Doppler measurement is positive (the frequency is higher):
푅푅푖 = −(퐷푖 − 푓푑 )휆 + 휀 (4.3) where 푅푅푖 is the range rate of satellite i, 퐷푖 is the Doppler measurement of the same satellite, fd is the receiver clock frequency drift, 휆 is the wavelength of the carrier frequency (휆 of
GPS/Galileo L1/E1 signals of fc= 1575.42 MHz is c/fc≈ 19 cm), and 휀 represents the errors in the measurement (e.g. frequency misalignment, receiver noise, etc.).
4.3. General Description of the Proposed Algorithm
This section describes the algorithm to instantaneously calculate the position and time of a receiver based on satellite radiofrequency signals with very inaccurate, initial receiver timing or information and no position information. It is based on the instantaneous Doppler positioning algorithm and estimates the coarse time offset by introducing an additional
11The notation has been adapted to the one used throughout the dissertation
129 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION unknown to the state vector, and relating it to the range rate measurements through the acceleration of the satellites as seen by the receiver.
Figure 43 – Satellite range rate variation over time Figure 43 depicts, for the case of one satellite and a receiver located at P0, the estimated range rate RR(t0) at time t0 and the measured range rate RR(t1) at time t1 between the satellite and the receiver. It also depicts the estimated unit vector 푒̅ pointing from the receiver to the satellite. Satellite-to-receiver range rate RR(t0) at an instant t0 and at an instant t1 RR(t1) differ by a magnitude that can be approximated by the time increment between t1 and t0 multiplied by the satellite-to-receiver relative acceleration.
Figure 44 depicts how the satellite-to-receiver acceleration a can be estimated as the time derivative of the range rate, that is, the increment in range rate (ΔRR) divided by the increment in time (Δt):
푎 = 훥푅푅/훥푡 (4.4)
This acceleration relates the estimated range rate at t0 with the actual or measured range rate at t1 according to the equation
푅푅(푡1) ≈ 푅푅(푡0) + (푡1 − 푡0) ∙ 푎 (4.5) where RR is the range rate, and a is the time variation of the range rate, or satellite acceleration relative to the receiver.
130
Figure 44 – Satellite-to-receiver acceleration estimated as range-rate variation over time t1 and t0 can differ by several hours, and the assumption that the acceleration is constant may be still valid for approximating to the correct time. Figure 45 depicts the range rate and satellite acceleration (or Doppler rate, or second range derivative in time) relative to the receiver.
Figure 45 – Range rate (i.e. the sign-reversed Doppler shift), and relative acceleration over a satellite pass. Relative acceleration can be approximated by a constant
131 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
4.3.1. "Cold Snapshot" Equations for a Static Receiver
For simplicity, we start with the description of an algorithm for a static (or slow-moving) receiver. We assume the receiver is static, or moving at a relatively low speed (<100 km/h), which allows the receiver velocity to be approximated to zero. In this static case, the proposed state vector to be solved is
푋 = (푥, 푦, 푧, 푓푑, 푡푐) (4.6) where x, y and z are the receiver coordinates, fd is the receiver clock frequency drift, and tc is the time difference between the initial time t0 and the actual time t1. In this case, the proposed system of equations is solved to estimate the state vector:
훿푥 훿푦 푖 −훿퐷 = [−푒′ 1 푎푖] 훿푧 + 휀 (4.7) 훿푓푑 [훿푡푐 ] where 훿퐷 corresponds to the vector of the differences between the Doppler measurements (in m/s) and the Doppler estimation from the satellite data and a previous position and time, which for the first iteration is set to P0 at t0. It is multiplied by -1 to convert Doppler measurements into range rate measurements, 푎푖 is the satellite-i-to-receiver relative acceleration, and 휀 is the error associated to the measurements and the linearisation process. This system of equations is similar to that in [5] (8.7). It can be solved by a standard iterative method where the 훿퐷 and the state vector 훿푥, 훿푦, 훿푧, 훿푓푑, 훿푡푐 provides an update to the next iteration.
If the receiver is dynamic but has a sensor or sets of sensors that provide measurements of the receiver velocity, the measurements can be subtracted from the Doppler measurements and we can apply the equations for a static receiver. Velocity could be determined from an inertial unit, odometer or any other source or signal. By having a static receiver or not estimating the receiver velocity as part of the unknowns, the number of visible satellites can be reduced to at least five, or at least six if the measurement residuals are verified. If the frequency drift is known or very low, the number of visible satellites can be reduced to at least four, or five if residuals are verified.
132
4.3.2. "Cold Snapshot" Equations for a Dynamic Receiver
Before providing the equations for a dynamic receiver, we mathematically derive "cold snapshot" system of equations. The system of equations presented in (4.7) can be obtained by differentiating in time the coarse time navigation equations in (4.1):
훿푍′ = 퐻′훿푋 + 퐻훿푋′
훿푥 훿푥′ 훿푦 훿푦′
−훿퐷 = [−푒푖′ 0 푅푅푖′] 훿푧 + [−푒푖 1 푅푅푖] 훿푧′ + 휀 훿푏 훿푏′ [훿푡푐] [훿푡푐′] (4.8)
훿푣푥 훿푥 훿푣푦 ′ 훿푦 = [−푒푖 푎푖] [ ] + [−푒푖 1 푅푅푖] 훿푣푧 + 휀 훿푧 훿푓푑 훿푡푐 [ 0 ]
When the receiver is static (or moving slowly), the relative velocity is zero, and therefore the system of equations becomes that in (4.7). When the receiver velocity needs to be taken into account, the system of equations is as follows:
훿푥 훿푦
훿푧 훿푣푥 −훿퐷 = [−푒′푖 −푒푖 1 푎푖] + 휀 (4.9) 훿푣푦 훿푣푧 훿푓푑 [ 훿푡푐 ]
The derivative −푒′푖of the receiver-to-satellite unit vector for a given satellite at position 푆̅ and a receiver at position 푅푥̅̅̅̅, with a range r between the two, can be calculated as follows:
133 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
푟̅ 푒 = 푟
1 푒′ = ( )[푟̅′푟 − 푟̅푟′] 푟2 (4.10) 1 = ( )[ (푉푠̅̅̅̅_̅푟푥̅̅̅)푟 − (푟̅)푅푅] 푟2
1 = ( ) (푉푠̅̅̅̅_̅푟푥̅̅̅ − 푒푅푅) 푟 where 푉푠̅̅̅̅_̅̅푟푥̅̅ is the vector of satellite velocity relative to the receiver. A similar expression is found in (8.6) of [5].
4.4. General Algorithm Implementation Including Long Time Uncertainty Periods
The logic flow diagram is presented in Figure 46. The proposed algorithm can solve a time ambiguity of some hours in one shot. However, for longer time ambiguities, the algorithm can be run several times in different intervals of some hours, and the residuals of each solution can be verified to assess if the solution is plausible or not. This section explains this process in more detail. It also explains all the steps, from the signal reception to the PVT computation.
First, the receiver receives the radiofrequency signal stream containing the satellite signals later used for positioning. It then filters, amplifies, conditions and digitises the signal stream to generate digital samples containing the satellite signals, which are usually under the thermal noise level in the case of GNSS signals.
Then, the receiver processes the samples to obtain the range rate measurements. In the case of direct sequence spread spectrum signals as GPS, this processing is usually subject to a signal acquisition engine in which the digital samples are correlated with replicas of the signal spreading codes at different time offsets and frequencies. As an outcome of the acquisition stage, measurements for each satellite of the satellite-to-receiver Doppler and range can be obtained. Range rate measurements can be obtained from frequency Doppler measurements as well as code phase difference measurements or carrier phase difference measurements.
134
Figure 46 – Logic flow diagram of the "cold snapshot" algorithm A receiver using this algorithm requires the knowledge of the satellite positions during the time uncertainty interval. If satellite clock drift impact is non-negligible, it could be required as well as part of the satellite data. In standard receiver architectures, the receiver decodes this information from the data modulated on the satellite signal (50 bps in GPS L1 C/A signals), a process which may last several tens of seconds in good reception conditions for each satellite. In snapshot positioning, this data cannot be demodulated and needs to be obtained from another source: previously demodulated ephemerides from the signals, satellite data downloaded from a server, long term orbital predictions from the satellites, satellite almanac data, which provides long term satellite orbits with a precision of some kilometres and which can be a valid source depending on the accuracy desired for the position to be calculated, or other sources. These data can be formatted in standard orbital Keplerian parameters that can be interpolated to a given time reference, satellite position, velocity and acceleration models, or other formats, as long as they allow the estimation of the satellite positions at a given time.
135 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
In addition to the satellite data, the proposed algorithm requires the definition of an initial time reference t0 and position reference P0. The accuracy of the initial position P0 is not relevant. Therefore, the position P0 can be set to the Earth centre, or the centre of the polygon formed by the satellite ground projection at t0 for the observed satellites. As regards the accuracy of the initial reference t0, it can differ from the actual measurement time in several hours. If the time error is in the order of hours, one computation may be sufficient. If the time error is higher, several computations with different time references over the uncertainty interval may be required, as described later.
For a given position and time pair (P0, t0), the proposed method obtains the receiver position, velocity, timing and frequency offset in the following step by resolving Equations (4.8) or (4.9), depending on the receiver dynamics.
If a position with a higher accuracy needs to be obtained, existing methods can use this initial position and time for a coarse time navigation solution using pseudorange measurements as described in prior art [64] [5], allowing an accuracy in the meter-level, or even below, depending on the accuracy of the code phase measurements.
We can see that the range rate function is not in general linear over time, and therefore the acceleration is not constant, as here approximated. The validity of the proposed approximation is in the order of a few hours, as demonstrated in later sections of this chapter.
We can also observe that the range rate measurement depends on the satellite clock frequency drift. This drift can be added to the measurement estimation, or neglected in the case of navigation satellites with highly stable atomic clocks. The estimation of the acceleration can be also taken from the satellite data and can be further refined by adding a linear time-varying components, as jerk, or higher order components, in order to refine the range rate estimation at a different time and improve the convergence period.
Once a solution is obtained, the algorithm checks if the obtained solution (P1,t1) is considered plausible, meaning that it is near the Earth surface and any standard integrity check related to the solution residuals does not show any anomaly. If this is the case, the solution is stored for later use and reported as an output of the method.
If the time uncertainty is reduced to some hours, only one iteration is performed. After the process of calculating the position and time of the receiver is terminated, the method ends.
136
However, if the time uncertainty is higher, several iterations with different initial times can be performed if needed, and as shown graphically in more detail in Figure 47.
When the time uncertainty period is too long and in the order of many hours, days, weeks or even months, the abovementioned system of equations will not converge to an adequate solution, due to the linearization errors of non-linear equations or other motives. A solution to this problem is presented in Figure 47, which consists of calculating a solution for several initial times. A way to implement this method is to split the time uncertainty interval into sub-intervals, define an initial time t0-i (T0-1, T0-2, T0-3, etc.), for each interval, and calculate a solution for each initial time. If the method converges to a plausible solution for a certain interval, the obtained measurement residuals, in case of an over-determined solution, will be below a certain threshold. The proposed method calculates an indicator of the residuals magnitude for each solution P1 at T1-1, T1-2, etc. It can also include the distance between the estimated height and the Earth surface to validate the position.
4.4.1. Orbital Repeatability and Advantages of Multi-GNSS
As shown in Figure 47, if the time uncertainty interval is too broad, there will be periods of non-convergence, where the initial time is far from the correct time of the measurements T1 and the method does not converge to a plausible low-residual solution, and periods of convergence, wherein the initial time is close to the actual time and the method will converge to a plausible solution. However, for every solution, there may be several plausible solutions due to the orbital repeatability of navigation satellite orbits, which leads to low-residual solutions at wrong times.
137 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 47 – "Cold snapshot" algorithm run for different periods Due to this effect, a low residual solution can be obtained with a fixed periodicity, which may occur every 6 hours (1/2 GPS orbital period), and will always occur every 12 hours in the case of GPS. Every 12 hours a very low residual solution is found associated to a position at the opposite side of the Earth. Given the 12-hour orbital repeatability of GPS, every 12 hours there will be a plausible solution at the same latitude but opposite longitude of the Earth. The satellites will have completed their orbits and will be exactly at the same positions, but the Earth will have turned 180º only. This effect is illustrated in Figure 48. The figure shows in two dimensions the solution of four Doppler measurements (a line, instead of a cone) from four sources, after one orbital period, after which the inner grey disk has rotated only 180º. (One can also infer from the figure that if only the satellites of one orbital plane would be taken in a solution, there would be a low-residual solution at all times.)
138
Figure 48 - Low-residual GPS orbital repeatability – 12-hour effect This +/- 12h solution may pass the coarse-time Doppler residual thresholds and can only be discarded at the later coarse-time pseudorange algorithm step.
A way to solve this problem is to use measurements from at least two satellites, each from a different satellite constellation like GPS, GLONASS, Galileo or Beidou, and with a different orbital period, to avoid the periodic repeatability of range rates from satellites from a single constellation. In this case, the range rate repeatability period will correspond to the minimum common multiple of the orbital periods of the satellites used. Therefore, by using more than one constellation, the proposed method leads to a single low-residual solution over a period of even several days. Figure 49 shows that only solutions including the correct time T1 will be accepted as plausible solutions (T1-2, T1-3), and solution T1-5 will be discarded.
Figure 49 – "Cold snapshot" algorithm run for different periods with different GNSS to avoid low-residual wrong solutions due to satellite orbital repetition
139 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
4.4.2. "Cold Snapshot" with Coarse Time Pseudorange Navigation
The "cold snapshot" method when based only on Doppler measurements will not yield an accuracy at the meter level unless the signal carrier phases are stably tracked for some time. However, it can be used to calculate a more accurate instantaneous position and time based on range measurements. For this, methods to resolve the code phase integer ambiguity to compute a full range measurement from an instantaneous fractional range measurement without integer rollovers may be required, as the one proposed in Ch.5 of [5]. Several solutions (P1, t1) may be obtained and stored from the "cold snapshot" algorithm applied over a broad time uncertainty interval (e.g. those associated to T1-2, T1-3 and T1-5 in Figure 50). Some of them may be wrong, due to the orbital repeatability, even if residuals are low (those of T1-5).
Figure 50 – Pseudorange solution residual computation to determine the right "cold snapshot" solution In case a wrong initialisation solution (e.g. T1-5) enters the coarse time pseudorange navigation block, the residuals will declare it as incorrect. The residual threshold in this case will be much lower than in the coarse time Doppler case, commensurate with the accuracy of the range-based solution.
If the solution is incorrect, we expect a high-residual output so it will be discarded. If the solution is correct we expect a low-residual output and it will be considered as correct. An over-determined solution is required to generate an indicator of the measurement residuals, and the application of orbital and clock corrections to satellites at instants that differ by several hours or days to the correct time of applicability, will lead to positioning errors that will be reflected into a solution with higher residuals, as shown in Figure 50. Interestingly, thanks to the orbital imperfections and clock drifts, the algorithm is able to work with time
140
uncertainties of several days, which would not have been possible if the satellite orbits and clocks were perfectly estimated by the ground segment.
Figure 51 – Logic flow diagram of the "cold snapshot" algorithm combined with coarse time navigation 4.4.3. Hardware Implementations and Applications of the Proposed Algorithm
The proposed algorithm can be implemented in a receiver-server architecture, as shown in Figure 52. In the figure, the receiver captures data snapshots regularly or triggered by certain events (for example a signal received, a movement detected, etc.), and stores them into a memory unit. Then, at a certain time, the receiver sends the snapshots to a server. The receiver may not have an accurate or continuous time reference, so snapshots may not be time-tagged. The server then receives the snapshots and resolves the position and timing for each of them through the proposed algorithm, by having satellite position and clock data for the interval of analysis.
141 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 52 –Receiver-server implementation of "cold snapshot" Applications of the proposed algorithm may include any location trackers that do not foresee to be continuously on, for power saving purposes or any other purposes. For example, one can think of a small and low-power tracker that is stuck to a container travelling worldwide. It will be switched on just sporadically, for example, when an alert is received through mobile networks or DSRC (Dedicated Short-Range Communications), its solar battery has been charged to a certain level, or it is subject to a movement captured by inertial sensors. At this point, if the tracker has been completely switched off, it may not have a clock providing a reasonably accurate time reference. The tracker just wakes up after a long sleep without having a clue of when or where it is. There may be similar use cases for animal tracking or for the internet of things, or just as a backup system for devices that are usually connected to the network, but may not be in some occasions, as a smartphone powered on in another country having lost its time reference. Other applications could also integrate any physical or biometric sensors tied with the snapshot position data, for example, for animal or human tracking.
4.5. Experimental Results
This section presents some experimental results of the proposed algorithm. The results are based on real GPS snapshot data captures. A Matlab-based snapshot receiver for GPS L1 C/A has been developed, based partly on [13]. Six data captures have been analysed, all showing similar results. They are summarised in Table 20. ID1 was available from [13]. IDs
142
2, 3, 4, 5 were available at the DGC from the experimental work of O. Badia [67]. ID6 was obtained by courtesy of UAB SPCOMNAV Group from Prof. Seco-Granados.
Table 20 – Summary of data captures
ID Data capture Sampling Intermediate Location Date Data Number configuration Frequency Frequency Analysed an file [Hz] [Hz] Duration of Snapshots Calculated 12 1 20050507- 38.192e6 9.548e6 University of 7th May 200 ms 20, 10ms col-1s.cfg Boulder, 2005 Colorado, U.S. 2 20100302- 16368e3 4129945 Danish GPS 2nd 200 ms 20, 10ms dgc-1s.cfg Centre, Aalborg, March Denmark. 2010 3 20100325- 16368e3 4129945 CTAE, 25th 200 ms 20, 10ms ctae-1s.cfg Barcelona, March Spain 2010 4 20100427- 16368e3 4129945 Danish GPS 27th April 200 ms 20, 10ms dgc-1s.cfg Centre, Aalborg, 2010 Denmark. 5 20100617- 16368e3 4129945 Gallecs, 17th June 200 ms 20, 10ms glcs-1s.cfg Barcelona, 2010 Spain 6 20140212- 16.368e6 4.092e6 Universidad 12th 200 ms 20, 10ms UAB-s1m1- Autónoma de February 30s.cfg Barcelona, 2014 Barcelona, Spain
ID1 and ID4 are not reported: For ID1, the reference position was not known. For ID4, the reference position is the same as ID2 and the results are similar. ID2 and ID6 are reported in more detail, as an example of all the other captures. The process followed in the snapshot receiver is based on three steps: Acquisition, Coarse Time Doppler and Coarse Time Code Phase. They are described after presenting the test configuration.
4.5.1. Configuration
Here are the configuration parameters of the ID2 and ID6 datasets.
True Position (Lat[º], Long[º], h[m, WGS84]): o ID2: 57.01473071 , 9.9859041 , 59.998 o ID6: 41.50408 , 2.09924 , 209.009 True time:
12 The snapshot function left 1ms unprocessed between snapshots. This is why a total of 220ms was read, out of which 10 ms out of 11 ms of data were processed.
143 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
o ID2: 2010/3/2 , 12:14:04 o ID6: 2014/2/12 , 15:15:00 Initial position (X,Y,Z): (0,0,0) Initial time: o ID2: 2010/2/2 , 02:00:00 (28.43 days error) o ID6: 2014/2/6, 04:00:00 (6.47 days error) Coarse Time Doppler Interval: 180 mins. Every 180 minutes a new solution is calculated. Number of solutions: 20. Elevation mask: 5º Integration Time for each solution: 10 ms. Coherent Integration time: 1ms Non-coherent integrations: 10 Doppler Solution - Residuals Threshold: 15 m (i.e. 78.9 Hz for L1) Code Solution - Residuals Threshold: 500 m. Maximum Height: 20000m (above WGS84 geoid). Acquisition Method: code-phase parallel acquisition. Acquisition Frequency Bin Step: 500 Hz.
All tests were performed over static receivers. The satellite ephemerides for the time uncertainty period are obtained from RINEX Navigation files downloaded from a server (ftp://cddis.gsfc.nasa.gov).
4.5.2. Signal Acquisition
First, acquisition is performed over a data snapshot. Acquisition leads to a set of Frequency/Code-Phase bins for the acquired satellites. Acquisition is performed coherently for 1 ms with 10 non-coherent integrations, for a 10-ms total. The signal acquisition method used is based on the non-coherent code phase parallel acquisition. It is described in [13] and [67], and depicted in Figure 53. It is based on the following steps:
For each frequency bin, the signal is converted to baseband in its I and Q components by multiplying by the carrier. The resulting complex baseband signal is transformed through a discrete Fourier transform (DFT) into a function in frequency.
144
The PRN code under search is also transformed through a DFT. The two frequency functions (signal and code) are multiplied, which is equivalent to their convolution in time. The inverse Fourier transform of the multiplication of the signal and code is calculated. If the signal is found, a peak will be observed at a given time, corresponding to the code phase measurement. If not, no peak is observed.
Figure 53 – Block diagram of Code phase parallel acquisition [13] 4.5.2.1 Fine Tuning for Open-Loop Code Phase and Frequency Accuracy
One of the limitations of open-loop positioning is that, without any additional processing, the code phase accuracy is limited by the sampling frequency. If parallel code acquisition is performed, the acquisition peak will tell which the sample with the highest peak is, but the actual code delay will usually be between samples.
Assuming that the peak is close to sample T, to obtain a more accurate delay measurement, interpolation between the samples T-1, T and T+1 can be performed. For that, the acquisition values for these three samples can be fitted to a function, and the maximum of the function will provide the peak. [65] proposes two types of interpolations: quadratic and piecewise linear. The quadratic interpolation fits the correlation results with a parabola, and the piecewise linear with a triangle. In the current implementation, the quadratic interpolation has been used, as it is shown by the above reference that its results are similar in the presence of noise.
145 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 54 - Quadratic Peak Interpolation - Sample '1' corresponds to the peak. Sampling Frequency = 16.368e6. GPS PRN 2 in ID6 data capture, first snapshot. As regards frequency accuracy, once the code phase measurement has been obtained, the signal can be de-spread to leave only the frequency carrier, and transformed through DFT into a function of frequency, in which the maximum provides the fine-tuned Doppler measurement.
The acquisition results for ID2 and ID6 scenarios are shown below in Table 21. For each scenario, the results show the PRN of the satellite acquired; the frequency, which is around the front end intermediate frequency fif; the measured Doppler; the code offset, in samples; the acquisition peak metric (compared to the second peak); the predicted Doppler for the actual position; the difference of the two; and the elevation and azimuth of the satellite. All Doppler measurements are given in Hz.
Table 21 – ID2 and ID6 acquisition results
ID2 - DGC *======*======*======*======*======*======*======*======| PRN | Frequency | Doppler | Code Offset | Peak Metric | Dopp Pred | Dopp Diff | el[º],az[º] | *======*======*======*======*======*======*======*======| 4 | 4.13386e+06 | 3913 | 15349 | 15.62 | 3125 | 788 | 26, 302 | 11 | 4.12733e+06 | -2612 | 8070 | 11.84 | -3393 | 781 | 31, 164 | 12 | 4.13028e+06 | 338 | 7408 | 5.47 | -438 | 776 | 9, 347 | 13 | 4.13461e+06 | 4670 | 6089 | 4.26 | 3888 | 782 | 19, 205 | 17 | 4.12949e+06 | -450 | 4456 | 16.86 | -1232 | 782 | 37, 262 | 20 | 4.13048e+06 | 533 | 5112 | 24.97 | -181 | 714 | 85, 147 | 23 | 4.13341e+06 | 3468 | 3229 | 38.07 | 2691 | 777 | 47, 193 | 30 | 4.13180e+06 | 1860 | 11739 | 3.22 | 1080 | 780 | 7, 17 | 31 | 4.13081e+06 | 861 | 10530 | 13.87 | 77 | 784 | 31, 66 | 32 | 4.12869e+06 | -1254 | 14314 | 23.27 | -2037 | 782 | 54, 87 *======*======*======*======*======*======*======*======ID6 - UAB *======*======*======*======*======*======*======*======| PRN | Frequency | Doppler | Code Offset | Peak Metric | Dopp Pred | Dopp Diff | el[º],az[º] | *======*======*======*======*======*======*======*======| 2 | 4.08893e+06 | -3067 | 15882 | 6.01 | -3026 | -41 | 11, 217 | 5 | 4.09190e+06 | -101 | 6552 | 25.00 | -68 | -34 | 72, 255 | 7 | 4.08913e+06 | -2872 | 16355 | 3.05 | -2912 | 39 | 28, 50 | 8 | 4.09056e+06 | -1444 | 10912 | 22.46 | -1417 | -27 | 62, 45 | 9 | 4.09067e+06 | -1327 | 12274 | 33.04 | -1295 | -32 | 67, 41 | 10 | 4.08863e+06 | -3372 | 1762 | 13.53 | -3403 | 31 | 32, 155
146
| 15 | 4.09482e+06 | 2818 | 14466 | 4.39 | 2863 | -45 | 19, 290 | 26 | 4.09365e+06 | 1655 | 3466 | 24.70 | 1686 | -31 | 54, 306 | 28 | 4.09360e+06 | 1600 | 11524 | 20.19 | 1568 | 32 | 44, 123 *======*======*======*======*======*======*======*======
We can observe that, for example, the Doppler difference is close to zero-average for ID6, meaning that the frequency drift of the receiver clock was low, while there is a bias of around 770 Hz per second in ID2.
4.5.3. Coarse Time Doppler Stage
Coarse Time Doppler time uncertainty windows of 3 hours (i.e. one coarse time Doppler computation every 3 hours) are selected because plausible Doppler solutions with GPS appear every 6 hours, as shown before (GPS orbits repeat every 12 hours; every 12 hours there is a plausible -low residuals- position in the opposite side of the Earth, same hemisphere, but every 6 hours there is a plausible Doppler position in the opposite hemisphere, as all the satellites are in the contrary hemisphere after 6 hours.
The proposed coarse time Doppler equations have been solved using a Taylor first order linearisation, as in the standard literature and a solution has been estimated through least squares [2] [5] [70]. If the solution is good, it is expected that the Doppler measurement residuals will be low. The algorithm therefore relies on the solution residuals to assess the correctness of the coarse-time Doppler algorithm.
To illustrate the residuals obtained, Figure 55 presents some magnitudes of instantaneous Doppler solutions over time. Note that in the coarse-time Doppler algorithm proposed, when in the proximity of a solution, the least squares approximation will converge to it. The plots present the residuals over a period between -10 hours and +10 hours around the correct measurement time.
Figure 55 top-left plot presents the measurement residuals. It shows that the residuals are very low at the correct time. It also shows some relatively low residuals at +/- 360 min, i.e. every 6 hours, or half the GPS 12h orbital period. The residual vector is in the order of 100 m/s, or 526 Hz. Other tests have shown similar low residuals.
Figure 55 top-right plot shows the actual position error, which is very high in all cases except at the right timing. The bottom-left plot shows the estimated clock frequency offset fo (or clock drift). For the right timing, it is shown that it crosses slightly above zero, i.e. at around 100 m/s. This implies that the frequency offset is around 100 / 0.19 = 500 Hz off per second,
147 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION or around 500 / 1575.42*106 = 0.3 ppm off, which is a clock stability one could expect from a TCXO receiver clock.
Figure 55 bottom-right plot shows the height of the estimated position, which is close to zero for the correct time, and not far from zero at +/- 6h. The low residual repeatability is further analysed in the next section.
Figure 55 - Instantaneous Doppler Positioning for scenario ID2 (DGC). Instantaneous Doppler solutions are calculated once every minute. Top-left: Doppler measurement residuals vector module. Top-right: Position error. Bottom left: Estimated frequency drift. Bottom right: Estimated position height. The measurement residuals of the every-3-hour CT-Doppler solutions are regarded for consideration in the CT-Code Phase solution. Only the position and time reference of below- threshold residuals solutions (residual vector below threshold), are considered for the CT- Code Phase stage.
4.5.3.1 Low Doppler Residuals due to GPS Orbital Repeatability
Figure 55 showed relatively low residuals every 6 hours, but generally not low enough to remain undetected by the residuals check. They may appear because a similar satellite geometry is found at the other hemisphere at 1/2 an orbit, possibly if all satellites would be allocated perfectly to their slots. The 6-h effect has not been analysed in detail as it is not found problematic, and is left for further study. However, the most problematic orbital repeatability effect is not shown in the figure and occurs every 12h for GPS, as explained before. As already mentioned, thanks to errors in the orbital and clock estimations, the
148
algorithm can discriminate at the coarse-time range algorithm between the correct and incorrect solutions. If orbits were perfect and clocks had no drift, all plausible Doppler solutions would pass the coarse time pseudorange solution threshold as well.
4.5.4. Coarse Time Navigation and Final PVT Calculation
As mentioned, the initial coarse time Doppler solutions are then used for the coarse time pseudorange algorithm. The measurement residuals of the coarse time code phase solutions are looked at, and the final solution taken has residuals below the threshold.
The PVT calculation has been performed by solving the system in Equation (4.1) through least-squares estimation. Once reconstructed, the pseudoranges can be approximated as follows (satellite indices have been omitted):
휌 = 푟 + 푏 + 퐼 + 푇 + 휀 (4.11)
Where 휌 is the pseudorange, 푟 is the actual range, b is the receiver clock bias, 퐼 is the ionospheric delay, 푇 is the tropospheric delay and ε is the error due to other factors: receiver noise, sampling and quantization, effects from the receiver clock drift, and multipath [2]. The tropospheric error has been estimated following [71], which is the function implemented in [13]. For the ionospheric correction, the Klobuchar model [72] broadcast by GPS has been used. A Klobuchar error correction model has been coded in Matlab for the experimental work of this dissertation following the GPS interface specification [11].
4.5.5. Results
As an example, below the screen outputs of the algorithm are shown. It shows that, in the ID2 run, the 5-state Doppler algorithm was run 241 times, and 85 low-residual solutions were found, out of which only one had low-enough code-phase residuals, which is considered the correct solution.
Table 22 – Example of "cold snapshot" algorithm outputs, ID2. The 5-state (coarse time) Doppler is executed for 241 possible initial times, separated by 180 min. each.
******************************************************** **** INITIAL CONDITIONS **** Initial(I):0.00000°N 0.00000°E -6378137.00m; 6363188.18m error Initial(II):2/2/2010 1:59:45 DOY 33, GPSw 1569, GPSs 180000s; -2456059s, - 28.43 days error
**** DOPPLER NAVIGATION **** Running 5-state Doppler 241 times... 85 solutions found
**** COARSE TIME NAVIGATION **** + + + PRCT nav(OK): (I):57.01473°N 9.98589°E 56.58m; 3.52m error; Mres:
149 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
10.497(m | m/s) + + + PRCT nav(OK): (II):2/3/2010 12:14:3.5389 DOY 61, GPSw 1573, GPSs 216858.5389s; -0.46113s, -0.00 days error
The rest of this section shows the final accuracy obtained for all scenarios except ID1 and ID4 (for ID1 –Colorado-, the exact position was unknown, and ID4 –DGC- results are similar to ID2).
The RMS-3D (Root Mean Squared, 3-Dimensional) error is in the order of 10-11 meters for ID2 and ID6, and around 31-33 meters for ID3 and ID5. The RMS-2D error (not to confound with 2drms error, as explained in [73]), is generally below 6.5 meters, except in ID3 which rises to around 11 meters. In this scenario, a bias in the average horizontal position can be seen in the figure, likely due to an error in the reference position used. In any case, the performance is not far from that of standard GPS receivers. The higher vertical than horizontal error may be due to ionospheric effects or geometry, which could be seen in the DOP (Dilution of Precision).
Figure 56 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold snapshot" results - Scenario ID2 - Danish GPS Centre, Aalborg. 2DRMS means RMS in 2 Dimensions (horizontal RMS)
150
Figure 57 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold snapshot" results - Scenario ID6 - UAB, Barcelona.
Figure 58 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold snapshot" results - Scenario ID3 – CTAE, Barcelona
151 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 59 – Left: Position errors of 20 10-ms snapshots. Right: Horizontal "cold snapshot" results - Scenario ID5 – Gallecs, Barcelona. 2DRMS error means RMS error in two horizontal dimensions. As the main purpose of the experimentation is to demonstrate the "cold snapshot" concept, a further characterisation of the accuracy results is out of scope. Taking into account that open- loop acquisition has been implemented, without any tracking loop fine-tuning or multipath mitigation strategy, and there accuracy of the measurements has not been the focus of this research, the performance are considered in line with the expectations.
4.6. Conclusions
This chapter of the dissertation has presented a new algorithm to instantaneously calculate PVT over snapshots without any position and time reference has been presented. The algorithm is based on the addition of one unknown to the instantaneous Doppler equations [5], which accounts for the time difference, which can be in the order of hours, allowing an iterative process to solve time uncertainties up to days, weeks or even months, by verifying the solution residuals. In principle, there is no limit in the time uncertainty, other than CPU time, which increases due to the higher number of iterations (8 per day with the current configuration). Using multi-GNSS to avoid orbital repeatability and some refinements to cope with non-linearities may reduce the number of iterations in a given period.
The algorithm has been implemented in a snapshot receiver in Matlab, validating the hypotheses. Accuracies of few meters have been obtained almost instantaneously with time uncertainties of several days.
152
Accuracy is not dependent on time uncertainty. The algorithm has implemented in a GPS L1 C/A snapshot open loop receiver (i.e. with no tracking loops) in Matlab. Accuracies obtained for the scenarios analysed are in the order of 6 to 11 meters 2D-RMS and 10 to 30 meters 3D- RMS, in line with the expectations.
153 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Chapter 5. Generalisation of Snapshot Positioning
5.1. Motivation
GNSS signals are received at a very low power (around -160 dBW). This makes GNSS positioning difficult indoors and vulnerable to interference. This chapter explores snapshot positioning with signals from satellites other than GNSS. In addition to currently existing satellites and constellations, as e.g. Iridium, Globalstar, Orbcomm or the hundreds of geosynchronous satellites in the geostationary belt, there are plans by some companies like Google or SpaceX to launch new satellite constellations for broadband worldwide internet connection [74]. A positioning system based on signals from other already existing and to-be- launched satellites could complement existing GNSS to make position, navigation and timing more available and resilient. The proposed method can add more ranging sources to a radionavigation solution, use stronger or broader bandwidth signals than those from GNSS to improve indoor localisation and add robustness against interference.
From a radionavigation service provider point of view, a snapshot based positioning system can be also advantageous, as it can reduce space segment costs by relying on existing satellites, simplify the on-ground estimation of satellite positions and clock errors and reduce risks and dependability of critical infrastructures as GNSS.
154
Figure 60 – Operational, Partly Operational and Spare Satellites, Apr. 2015 - source: Spacebook. Generic satellite signals may not be adequate for navigation for various reasons. First, they do not provide their position, so receivers need to get their position from another source. Second, if positioning is based on TOA or TDOA, the satellites need to be synchronised to a common time reference, and use stable clocks. In addition, the signals, due to their power and bandwidth, may not be suitable for accurate navigation.
The main motivation of this chapter is to study how snapshot positioning techniques can overcome these limitations. After presenting some well-known satellite communication systems and signals, and a snapshot method to locate a receiver using generic radiofrequency signals is presented. The proposed method requires a monitoring network of stations and a user receiver. It is based on the following steps: First, Both the user receiver and a ground segment with monitor stations spread across the region over which the service is provided, capture a snapshot of the signals that will be used for positioning. Then, the ground segment calculates the instantaneous position of satellites visible by at least four stations by triangulation. Finally, the user position is calculated based on the instantaneous satellite positions, velocities and clocks calculated by the ground segment, and the snapshot received by the receiver.
The proposed method, and a signal simulator allowing to do some testing, have been implemented in Matlab. The tests present the experimental results of snapshot positioning of
155 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION one satellite, based on a ground monitor station segment, and the snapshot positioning of a user receiver, based on the snapshot position and other reference parameters of four satellites.
5.2. Background
5.2.1. Overview of non-GNSS Constellations, Satellites and Signals
Satellite navigation signals and constellations have some common features that make them suitable for navigation. They use medium earth orbit (MEO) satellites with ultra-stable atomic clocks. Their signals are transmitted in the L band using spread-spectrum techniques, generally through multiple frequencies. They are received on Earth at a low power, -125dBm to -130 dBm, below the noise level. This section provides an overview of non-GNSS satellites and constellations, and assesses the suitability of some non-GNSS satellites and signals for navigation. Some references are provided where more detailed information can be found.
The Union of Concerned Scientists (UCS) provides an exhaustive list of satellites using general public information, including orbital description [75]. This database includes launches until 31 Jan 2015. 1265 satellites are listed at the time of this writing, for civil, governmental and military users, and for use in earth and space observation, communications and navigation. Around half of the satellites in the database are LEO satellites (669 out of 1265) and the other half is divided between GEO satellites (465), MEO (94) and elliptical (37).
GEO satellites are not the best for the method proposed in this chapter due to the geometric dilution of precision of snapshot triangulation, which significantly affects accuracy. For GEO-based snapshot positioning, the GEO satellites should be tracked continuously on ground, as is the case for SBAS GEO satellites, and then their reference parameters could be transmitted in snapshot mode to the user. As regards LEO satellites, they are (geometrically) more adequate for positioning, although they require a higher density of monitor stations to cover a given area.
A full characterisation of all satellites for positioning can be a daunting task and is considered out of scope of this chapter. However, some examples of popular constellations are provided here. The satellite systems described are O3b (MEO), Globalstar and Idirium (LEO).
156
O3b satellites fly at around 8000 km altitude. A constellation of 20 satellites is foreseen by 2015. They will provide a bandwidth of around 150 Mbps through signals in the Ka band, through FDMA, CDMA and TDMA combined modulation techniques [76]. The satellite-to- user frequency bands are foreseen in the 17.70 – 20.20 GHz range [77].
Around 45 Globalstar satellites currently orbit the earth at around 1400 km altitude. They are placed in 8 orbital planes at an inclination of 52 degrees, with 6 equally spaced satellites per orbital plane. They use the L-band (1610–1626.5 MHz) for user-to-satellite transmissions, and the S-band (2483.5–2500 MHz) for satellite-to-user transmissions, providing voice and data communications to mobile and fixed users [78]. Globalstar signals are modulated through an extension of IS-95 CDMA used for terrestrial communications. This means that signals combine FDMA and CDMA access techniques. For each frequency, the channel bandwidth is 1.23 MHz, for a chip rate of 1.2288 Mcps. Data channels used by Globalstar support 9600, 4800, and 2400 bps.
Iridium satellite constellation is composed by 66 satellites orbiting at 780 km height, in six near-polar orbital planes. They use the L-band (1616 to 1626.5 MHz bandwidth) and FDMA and TDMA signals. FDMA divides the 10.5 MHz bandwidth in 240 channels of 41.6 KHz. Due to its low orbit, Iridium satellites have a footprint radius of 2209 km [79] [80].
One of the major advantages of non-GNSS signals is that they are generally received at a higher power than GNSS signals. For example, in the case of Iridium, C/N0 of its signals received outdoors are in the order of 80 dBHz [81], i.e. around 35-40 dB higher than GPS signals. This allows the reception of the signals in highly attenuated indoor environments. Table 23 provides a summary of Iridium, Globalstar and O3b systems and signals.
Table 23 - Iridium, Globalstar and O3B system and signal properties. 13
13 "Iridium Satellite" by Cliff under CC BY 2.0 via Wikimedia. Globalstar satellite IMAGE from Globalstar. O3B Satellite image from TAS.
157 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
System Iridium Globalstar O3B
Nb. Sats aprox. 66 45 20
Orb. Heigth 780 km 1400 km 8000 km
Sat-to-User L S Ka Frequency Band Sat-to-User 1616-1626.5 MHz 2483.5–2500 MHz 17.70 – 20.20 GHz carrier frequencies Access FDMA, TDMA FDMA, CDMA FDMA, CDMA, TDMA Technique Signal 10.5 MHz 1.23 MHz ≥ 150 MHz bandwidth (1- sided) Bit/chip rate 50 Kbps 1.2288 Mcps 150 Mbps
In addition to the existing systems, there are some recent initiatives for deploying future commercial constellations: OneWeb proposes a satellite constellation to be composed of around 650 satellites for providing internet around 2019, with backing of Qualcomm and Virgin. Google has also presented plans of launching thousands of LEO satellites for various purposes [74].
5.2.2. Background on Positioning with Non-GNSS Satellites
This section presents a short overview of reported positioning techniques using non-GNSS satellites, and some references. One advantage of LEO satellites is that their signals have high varying Doppler shifts, as they move at higher relative speeds than MEO GNSS satellites. For example, Globalstar is known for offering a positioning service providing around 10-km accuracy [82]. Some research of positioning techniques using Globalstar satellites shows a method to instantaneously calculate a position with just one Globalstar LEO satellite [83]. The method is based on combining range and range rate measurements similarly to the method proposed in [5].
Concerning Iridium, work has been performed to combine Iridium signals with GPS signals [84], [85]. A system called IGPS uses Iridium fast-changing Doppler measurements to help solve carrier ambiguities and add robustness against failures. [86] proposes an integration of GPS and LEO communication signals for E911, in which LEO range rate measurements are combined with RF pattern matching to increase availability indoors. [87] also proposes
158
techniques to combine LEO satellites with GPS to enhance navigation capabilities. They rely on increasing geometric diversity (wrt. GPS alone) and helping the resolution of carrier phase ambiguities, achieving centimetre-level accuracy.
While the methods proposed improve significantly navigation performance and robustness compared to GNSS alone, they are based on the processing over a time interval of the signals. Even if they allow a relatively low time to fix, they are not strictly based on snapshot positioning techniques. More generally, the combination of GNSS and non-GNSS ranging sources is dealt with in the mobile location domain, where GNSS signals are combined with signals-of-opportunity from base stations [4] or wireless access points [88].
5.3. Signal and Error Model
This section proposes a signal and error model for the snapshot generalisation proof-of- concept. This model follows standard models used in GNSS literature. The main difference with standard models is that the satellite frequency drift is explicitly taken into account, to model high frequency drifts from satellite clocks that are not as stable as GNSS satellite clocks. This term is very small in GNSS satellites and is generally neglected in other models.
For the snapshot generalisation proof-of-concept, a signal as it should be transmitted at an instant t by a satellite can be modelled as follows:
푠(푡) = 퐴퐶(푡) cos (2휋푓푐푎푟푟푡 + 휑(푡)) (5.1)
Where A is the signal amplitude, 푓푐푎푟푟 is the signal carrier frequency, 휑(푡) is the signal phase offset and C(t) is a sequence of [+1,-1] symbols, each of period TC, when the signal is transmitted, or zero when the signal is not transmitted (allowing to represent TDMA signals). The proposed signal assumes a PSK (Phase Shift Keying) modulation. C(t) represents a sequence of chips irrespectively from whether they belong to spreading codes or useful data sequences. Now, we can model the signal as actually transmitted by the satellite, affected by a bias and a drift, as follows:
푠푡푥(푡 + 푏푡푥) = 퐴퐶(푡) cos(2휋(푓푐푎푟푟 + 푓푑푡푥)푡 + 휑) + 휀푡푥 (5.2)
Where 푏푡푥 is the time bias in the satellite clock at instant t, 푓푑푡푥 is the satellite clock frequency drift at instant t, and 휀푡푥 is the signal error due to other factors (e.g. signal filtering, carrier-code coherency, etc). Note that 푏푡푥 is the time derivative of 푓푑푡푥, and therefore is
159 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION time-dependent, but this is not reflected in the equation. Snapshot positioning performance is not so sensitive to the time variation of the errors, but to their absolute value at the snapshot positioning time.
The signal, transmitted at 푡 + 푏푡푥, is subject to errors in its propagation through the atmosphere. When the signal arrives at the receiver, it arrives with a delay τ due to the distance between the satellite and the receiver and additional propagation delays in the atmosphere and local and filtering effects. This last term accounts for the errors due to receiver filtering, code misalignment, quantization, frequency misalignment and multipath. At reception, the frequency of the signal is modified due to the Doppler effect. Therefore, when received and down-converted to intermediate frequency 푓퐼퐹 , the signal can be modelled as follows:
퐼 푇 ε 푠 (푡 + 푏 + τ + 휌 + + 휌) = 퐴퐶(푡) cos(2휋(푓 + 훥푓)푡 + 휑) + 휀 + 휀 (5.3) 푟푥 푡푥 푐 푐 푐 퐼퐹 푡푥 푟푥 where 퐼휌 corresponds to the ionospheric range error in the pseudorange, 푇 is the tropospheric range error, and ε휌 models other error effects. This last term accounts for the errors due to receiver filtering, code misalignment, quantization, frequency misalignment and multipath,
휀푟푥 corresponds to other non-modelled errors in the receiver. 훥푓 is the frequency difference at which the down-converted signal is found with respect to 푓퐼퐹, and can be modelled as follows:
훥푓 = 퐷 − 푓푑푟푥 + 푓푑푡푥 (5.4) where D is the Doppler effect due to the relative satellite-to-receiver velocity and equivalent to minus the range rate, and 푓푑푟푥 is the frequency drift in the receiver clock. Note that the receiver clock drift has the inverse sign of 훥푓: the faster the receiver clock is running, the 'slower' the signals appear to arrive, so signal appears to the receiver to have a lower frequency.
Equation (5.3) represents the signal in the reference time scale at reception time. However, the receiver is not synchronized with this time scale. It just has its own reference time 푡푟푥 that relates to the absolute time t by a bias 푏푟푥.
푡푟푥 = 푡 + 푏푟푥 (5.5)
160
Therefore, the signal, as time-tagged by the receiver in its own local time scale, can be represented as follows:
퐼휌 푇 ε휌 푠 (푡 − 푏 + 푏 + τ + + + ) = 퐴퐶(푡) cos(2휋(푓 + 훥푓)푡 + 휑) + 휀 + 휀 (5.6) 푟푥 푟푥 푟푥 푡푥 푐 푐 푐 퐼퐹 푡푥 푟푥
The receiver therefore receives the signal at 푡푟푥 − 푏푟푥 + 푏푡푥 + τ + 퐼휌/푐 + 푇/푐. It can calculate the pseudorange 휌(t) as the estimated difference between signal transmission and reception times t and trx, multiplied by the light speed.
푠푟푥(푡푟푥 + 휌(푡)/푐 ) = 퐴퐶(푡) cos(2휋(푓퐼퐹 + 훥푓)푡 + 휑) + 휀푡푥 + 휀푟푥 (5.7)
휌(푡) = 푐(τ − 푏푡푥 + 푏푟푥) + I휌 + T + ε휌 (5.8)
5.3.1. Ranging Accuracy Estimation Through the CRLB
The positioning accuracy generally depends on two aspects: the DOP and the ranging error. The DOP can be calculated from the equation system covariance matrix as described in [2]. As regards ranging accuracy, the Cramér-Rao Lower Bound gives the lower bound of the variance of an unbiased estimator.
A didactic description of the CRLB in the frame of signal estimation theory is given Chapter 3 of [89] for different parameters to be estimated, such as frequency, carrier-to-noise or range. In our case, the parameter to estimate is the satellite-to-receiver range. Depending on how this parameter is estimated, the CRLB can be expressed in various ways. According to (3.38) of this reference, the CRLB for range estimation can be expressed as:
1 푣푎푟(휏̂0) ≥ 퐸 ̅̅̅2̅ (5.9) ( 푁0 ) 퐹 2
T 푑푠(푡) 2 ∫ 푠 ( ) 푑푡 퐹̅̅̅2̅ = 0 푑푡 (5.10) T푠 2( ) ∫0 푠 푡 푑푡
Where 휏̂0 is the estimated range, 퐸 is the integrated signal energy between 0 and Ts and 푁0 is the noise power density. The factor 퐹̅̅̅2̅ is indeed the mean square signal bandwidth. Therefore, the higher the bandwidth, the lower the variance of the estimator, and the higher the accuracy. We can therefore summarise by saying that, according to the CRLB, the signal
161 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION accuracy depends on a) the signal power to noise ratio, b) the signal bandwidth, and c) the signal integration time in the receiver.
The abovementioned expression is suitable for our purposes under open-loop snapshot positioning techniques, as it is not particularised to tracking loop parameters as e.g. tracking loop bandwidth, but it is only dependent on the signals. Other expressions of the CRLB are presented in [90], Chapter 2. They are particularised to Pulse Amplitude Modulations (PAM), so they can also be used to the already digitalised signal. Chapter 3 of [91] also proposes a CRLB formula particularised for GNSS. The work in this chapter is based on estimating the CRLB based on Equations (5.9) and (5.10).
Considering that the target signals (mainly for communications) have a similar or wider bandwidth than GPS L1 C/A, and their power is expected to be higher than that of GNSS signals, and modern receivers allow long integration times, it seems worthwhile to consider positioning with the characteristics of these target signals.
Figure 61 – Maximum accuracy achievable (standard deviation) according to Cramér-Rao Lower Bound for different signal to noise density ratios and chip frequencies. 1-milisecond integration time
Figure 61 shows the accuracy signals at different C/N0 and chip (or bit) frequencies, for a relatively short integration time of one millisecond. The bandwidth used is equivalent to the chip frequency, and the sampling frequency is set to 4 times the chip frequency (Fs=4*Fc).
As expected, the figures show that high C/N0 and high bandwidths (i.e. high chip rates) lead to higher accuracies.
5.4. Description of the Method
With more details than above, the method here proposed is based on the following steps:
162
1) Capture and store a digital snapshot by a user receiver, on a given frequency band where the target satellite signals are transmitted. 2) Capture digital snapshots around the same frequency by several monitor stations synchronised to a common time reference. These snapshots shall include or overlap sufficiently in time with the snapshot captured by the user. 3) For a given satellite, estimate the range from the satellite to each monitoring station at a given common time reference. 4) Determine the instantaneous satellite position and clock bias solution at the common time reference based on the range measurements from at least four stations. 5) Determine the instantaneous satellite velocity and clock frequency drift solution at the common time reference based on the range measurements from at least four stations. 6) Perform steps 3) to 5) for up to at least four satellites. 7) Use the satellite position, velocity, bias and drift at the given time reference from at least four satellites, together with the satellite measurements obtained from the snapshot captured by the user receiver, to compute the user receiver position.
Each step of the process is described in detail in the next subsections.
5.4.1. Capture of User Receiver Snapshot
We assume that a user receiver is loosely synchronised with a time reference, say, UTC (Universal Time Coordinated) or GPST (GPS Time). The time reference chosen is not a driver for the system, as long as it is coherent in all steps involved. We assume a loose synchronisation of the receiver clock in the order of a few milliseconds, although a looser synchronisation can be tolerable by extending the snapshot capture period accordingly. If the signals to be used are transmitted continuously by the satellites (which is generally the case) and can be properly demodulated and/or correlated by the ground segment, the user receiver could take a snapshot at an arbitrary time reference.
The receiver captures a snapshot of digital samples associated to a time interval of length/duration Δ between (tstart, tend). At this stage, the user receiver does not necessarily know the properties of the signal to correlate, other than the bandwidth to capture and the time interval during which the signal is correlated.
163 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
We consider two cases. In the first one (Case A), the snapshot capture is totally asynchronous, i.e. the receiver captures the snapshot without any synchronisation whatsoever. In the second one (Case B), the receiver is loosely synchronised with a time reference.
5.4.1.1 Case A – No Synchronisation
This is the simplest case for the receiver. The receiver captures a snapshot without any constraint, assuming that signals usable for ranging are continuously transmitted by the satellites and will appear in the snapshot. The time uncertainty can be solved by the snapshot ground segment. In the below example, the receiver starts capturing the snapshot at its own estimation of t0, i.e. t0rx. The snapshot length is the minimum length required to correlate the signal, i.e. Δ = Δmin. This is shown in Figure 62.
Figure 62 – User receiver signal snapshot – Asynchronous case 5.4.1.2 Case B – Loose Synchronisation
In this case, the receiver correlates a snapshot of signals transmitted by each satellite j at t0tx,j, i.e. at the satellite's own estimation of t0, which altered by satellite j's clock bias. The minimum 'useful' snapshot duration required is Δmin, as in the previous case. The receiver must have an estimation of the maximum biases of the satellites' clocks and its own clock, and the maximum and minimum signal transit time. If this information is not known, a longer snapshot can be taken, to ensure that the desired signals will be captured.
The snapshot start and end times are
푡푠푡푎푟푡 = 푡0푟푥 + 휏푚푖푛 − 푏푟푥,푚푎푥 − 푏푡푥,푚푎푥 (5.11)
푡푒푛푑 = 푡0푟푥 + 휏푚푎푥 + 푏푟푥,푚푎푥 + 푏푡푥,푚푎푥 + ∆푚푖푛 (5.12) where 푡0푟푥 is t0 according to the user time reference, 휏푚푖푛 and 휏푚푎푥 are the minimum and maximum transit times of the signal respectively (휏푚푖푛 represents the case where the satellite is at the zenith, and 휏푚푎푥 can be bounded by 휏푚푖푛 plus the Earth radius*c), 푏푡푥,푚푎푥 is the
164
maximum user bias, 푏푡푥,푚푎푥 is the maximum satellite clock bias of any satellite extracted from the snapshot, and ∆푚푖푛 is the minimum useful snapshot duration time. The biases can apply in any sense, and this is why they are subtracted for 푡푠푡푎푟푡 and added for 푡푒푛푑. Thus, the user expects the satellites to transmit the signals expected at t0 between t0 - 푏푡푥,푚푎푥 and t0 +
푏푡푥,푚푎푥. In our case, we assume that the user does not have a priori knowledge of the receiver or satellite biases. If this were the case, the estimated biases should be taken into account and the total snapshot length can be reduced. Figure 63 represents the total snapshot start, length and end in a time scale. The target satellites do not necessarily use atomic clocks to synchronise its signals, and therefore the satellite clock biases and drifts can be similar to those in user receivers and have to be estimated. The effect in the snapshot duration of the user or satellite frequency drifts is considered negligible.
Figure 63 – User receiver signal snapshot – Synchronous case 5.4.2. Capture of Snapshot at Monitor Stations
In order for the user to calculate her position, the instantaneous position and time of the satellites used for the user position computation need to be known. For this, a snapshot ground segment is required. This ground segment is in charge of recording digital samples of the desired signals by a network of monitor stations, allowing computing the instantaneous position of the satellites. A ground segment of monitor stations scattered across a given service area and synchronised with a common time reference (e.g. through a GPS receiver) are required to capture data snapshots. Figure 64 depicts a ground segment formed by 5 monitor stations (m1 to m5). The figure depicts how these stations receive a signal from a given satellite at different times (t1 to t5), depending on the time of arrival of the signal.
165 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 64 - Satellite signal snapshot reception by a ground monitor network As the proposed system is a generalisation of snapshot techniques for different types of signals, no signal properties as carrier, modulation, bitrate, etc. are specified at this stage. However, it is assumed that the monitor stations are able to demodulate and/or correlate the signal and extract a sequence of bits or chips that can be used to compute the signal time of arrival.
Concerning the equipment required at the monitor stations, commercial off-the-shelf previously geo-located USRPs (Universal Software Radio Peripherals) with sufficient storage capabilities and synchronised to a GPS-based time reference through a 1PPS would suffice.
In any case, for the ground segment to provide the snapshot reference parameters, it is not mandatory that the ground segment use snapshot satellite positioning techniques. It can continuously track the satellites and estimate their parameters through Kalman filters or other techniques, as applied in current GNSS. However, for the rest of the chapter, and in order to assess snapshot ground segment performance, the proposed ground segment also uses snapshot techniques.
5.4.2.1 Case A – No Synchronisation
In this case, the relaxation of requirements in the user receiver would increase the requirements at the ground segment. The ground segment should continuously monitor the satellites by either tracking their signals in a classical way, or performing continuous
166
snapshot positioning. This general case is left aside of the dissertation and proposed for further work. The proposed concept is better explained through the loose synchronisation case.
5.4.2.2 Case B – Loose Synchronisation
In this case, each station would capture a snapshot of the signal in a similar fashion as in step 2), with the difference that, if the reference station is accurately synchronised with the time reference, the term 푏푟푥,푚푎푥 will be in the order of nanoseconds and can be neglected for the calculation of the snapshot interval. Therefore,
푡푠푡푎푟푡 = 푡0 + 휏푚푖푛 − 푏푡푥,푚푎푥 (5.13)
푡푒푛푑 = 푡0 + 휏푚푎푥 + 푏푡푥,푚푎푥 + ∆푚푖푛 (5.14)
We assume, for simplicity, that the stations are perfectly synchronised with the reference time and therefore the time estimation of t0 from all stations equals the actual t0. We also assume no knowledge of the satellite time biases.
5.4.3. Signal Acquisition and Satellite Range Estimation
To illustrate this case, let us assume that a monitor station of the "Snapshot Ground Segment" is able to time-tag the signals by correlating the received signal with a known pattern unique for the satellite (as done e.g. for GNSS DSSS signals), or demodulating the received signal, assigning it to a satellite based on its properties (carrier frequency, code sequences, etc.) and time-tagging the demodulated sequence. In this case, the signal to correlate (i.e. the "useful signal") is the snapshot of the signal appearing in white in Figure 65, and the method ignores all other parts of the signal. We assume that the system can determine the "useful signal" duration.
167 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 65 – Example of satellite signal time of arrival at different monitor stations (m1, m5)
5.4.3.1 Sliding Window Acquisition when ∆>>∆풎풊풏
Due to the satellite time bias uncertainty, there may be cases in which the time window to perform acquisition may be too long, compared to the effective integration time ∆푚푖푛. In this case, a snapshot acquisition based on a sliding window may be applied, as illustrated in the following example and Figure 66:
We capture a snapshot of Δ = 60 ms, where the "useful signal" is only 10 ms (Δmin)
and starts to be received at around tstart + 24 ms.
The snapshot is divided into sliding time windows. A snapshot is taken every Tslide (5
ms), with a duration of Tslide+ Δmin = 15 ms. Each 15 ms window the snapshot is correlated with the 10 ms length replica, plus zeros. In case the signal is acquired in more than one window (w3, w4, w5, w6 and w7 in the figure), the time window with the highest correlation can be taken (w5). We assume that other windows will only partially correlate the signal leading to a smaller peak. Assuming that the monitor station is under good visibility conditions, signal correlation should generally not be subject to high variations. The process can be performed more than once to increase robustness. The proposed sliding time window allows performing snapshot correlations over long periods without correlating the whole snapshot, although at the expense of correlating the same signal slices several times.
168
Figure 66 – Example of sliding window for snapshot acquisition. Highest correlation at w5. The acquisition search space must take into account the fact that the satellite clock drift is unknown. We assume, however, that monitor stations can have good clocks and their clock drifts are low. Therefore, and taking into account that they are static, the only factors contributing to the frequency search space are the satellite range rate and the satellite clock drift.
5.4.4. Instantaneous Satellite Position and Clock Calculation
Once a set of satellite-to-monitor pseudorange measurements are obtained from the acquisition process, the satellite position at a given time can be calculated.
The obtained pseudorange measurements 휌푖 and Doppler measurements 퐷푖 for each station i are subject to errors. Standard error models in GNSS literature are used here [2], as already mentioned in section 5.3. The main difference here is that, as opposed to calculating the position of a receiver based on 4+ satellites, we calculate the position of a satellite based on 4+ monitor receivers.
Classic position calculation methods in the literature involve Time Of Arrival (TOA) and Time-Difference Of Arrival (TDOA). While TOA is more popular for satellite navigation, TDOA, also known as hyperbolic positioning, is commonly used in communication systems. For example, 3GPP and LTE-based positioning use TDOA to locate a user transmitting a signal to the surrounding base stations [4]. In the current case, and given that the satellite transmission time is unknown, the two options available are:
Estimate a TOA solution with at least 4 stations, calculating the satellite position
(x,y,z) at the time the signal transmission started and a bias btx at t0. Estimate a TDOA solution with at least four stations, using a station as a reference and calculating the satellite position (x,y,z) at the time the signal transmission started.
169 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
TOA and TDOA methods yield equivalent results in terms of DOP if measurements errors are uncorrelated and homogeneous [92]. It is also proven in [93] that TOA and TDOA are equivalent in a general case, even with non-homogeneous and correlated ranging sources. It is recommended TOA over TDOA for simplicity in its implementation. Therefore, we propose to solve the positioning problem using the TOA equations, and calculating a bias term with respect to the time reference t0.
The following equation represents the satellite range determination through TOA for a monitor station i:
2 2 2 휌푖 = √(푥푗 − 푥푖) + (푦푗 − 푦푖) + (푧푗 − 푧푖) − 푏푡푥,푗 + 푏푟푥,푖 + I휌,푖,푗 + T푖,푗 + ε휌,푖,푗 (5.15)
where xj, yj, zj and btx,j are the satellite j position and bias unknowns, 푥푖, 푦푖 and 푧푖 are the coordinates of monitor station i, 푏푡푥,푗 is the clock bias of satellite j, 푏푟푥,푖 is the estimated bias of monitor station i, 퐼휌,푖,푗 , 푇푖,푗 and ε휌,푖,푗 are the ionospheric, tropospheric and other errors, respectively.
The system of equations can be solved following a Newton-Raphson method and linearising the equations through a first order Taylor series, as proposed in most GNSS literature already referred to in this dissertation. In case the system is overdetermined, a least squares estimator can be used to calculate the solution, as in standard satnav positioning, to minimise the squared residual errors. The following steps are performed iteratively:
훿휌 = 퐻훿푋 (5.16)
훿푋 = (퐻푇퐻)−1퐻푇훿휌 (5.17) where 훿휌 is an [m x 1] vector (m is the number of measurements) with the difference between the estimated and obtained pseudorange measurements for a given X, 훿푋 is the updated (x,y,z,b) solution with respect to the previous iteration, and H is the [m x 4] geometry matrix.
−푒1 1 퐻 = ( ⋮ ⋮) (5.18) −푒푚 1 where −푒푖 is the unit vector between the satellite i and the monitor station (note that i is not an exponent). As regards the initial position, in the case of standard satellite navigation, often
170
the position solution is initialised to a previously known value, or if no previous value is known, the position is initialised to Cartesian coordinates (0,0,0). In our case, the satellite initial position has been calculated by averaging the latitudes and longitudes of the stations acquiring the signal, and adding an average height of the satellite orbit (which can be easily known by the system. E.g. [94] provides real-time satellite information).
5.4.5. Satellite Velocity and Frequency Drift Calculation
The equations used to calculate the solution velocity and clock drift based on range rate (Doppler with inverse sign) measurements are similar to those for the position and bias calculation. They can be derived from the differentiation in time of the pseudorange equation system, as shown in (6.33) of [2].
−훿퐷 = 퐻훿푣 + 휀 (5.19)
훿푣 = (퐻푇퐻)−1퐻푇(−훿퐷) + 휀 (5.20) where 훿퐷 are the Doppler measurements and 훿푣 is the vector (vx, vy, vz, fd) of the satellite velocity and frequency drift.
5.4.5.1 Additional considerations about satellite clock errors
One of the main differences of GNSS-based positioning with respect to the proposed method is that satellite clocks cannot be assumed as highly stable in this method. In the current model, satellite clock errors have been modelled as a bias and a drift, whose magnitude can be in the order of standard TCXO clocks in marketable GNSS receivers. This assumption seems valid for very short snapshots, in which the clock drift can be considered as constant.
For much longer snapshots, including several hundreds of milliseconds, or even seconds, the satellite clock stability may become a limiting factor. To further understand its effect, more refined clock models, as for example those proposed in Chapter 11 of [95] or in [96], can be used.
5.4.6. Reference Parameters for at Least Four Satellites.
At the end of this step, the "Snapshot ground segment" is able to calculate the 3D-position, 3D-velocity, clock bias and drift of a set of satellites. Therefore, the user position computation process takes as an input for each satellite j the values pj(xj, yj, zj), vj(vxj, vyj, vzj), btx,j, fdtx,j referred to a given time t0. If unknown to the user, the system can also provide the
171 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
bit sequence needed to correlate the signal seqj. Without further processing, the position (xj, yj, zj) computed in step 4) refers not to t0 but to t0 + btx,j. The position can be translated to t0 by applying the calculated velocity, and assuming that during btx,j the velocity vector is constant, as follows:
푐휏(푡표) = 푐휏(푡푡푥) − 푏푡푥푅푅 (5.21) where RR is the range rate and c the light speed, so 푐휏 is the range. Figure 67 shows the parameters available as an input for the user position calculation, for j=1,2,3,4.
Figure 67 – Diagram showing the information available to the user: position(t0), velocity(t0), bias(t0), frequency drift and signal sequence to correlate from at least four satellites 5.4.7. User Receiver Position Calculation
Once the information for at least four satellites is available, a user receiver can easily calculate its own snapshot position by extracting the pseudorange measurements from the snapshot and applying standard techniques following equations (5.16) and (5.17).
5.5. Experimental Results: One Satellite Snapshot Positioning
This section describes the results of calculating the reference parameters of a satellite through snapshot positioning techniques in a ground segment including six ground monitor stations. First, the experiment configuration is presented, including the signal configuration parameters, error models, monitoring receiver parameters, and so forth. Then, the steps for the signal generation and satellite position computation are detailed. Finally, the results are presented. The purpose of the experiment is to validate the satellite snapshot positioning proof of concept and generally characterise its performance in a particular setup.
172
The signal and satellite analysed are fictitious. Their resemblance to GPS signals is due to the convenience of using code developed in other parts of the thesis. However, the analysis is considered generic enough so as to be extended to other signals. The satellite positions and velocities are fictitious as well and do not consider the earth gravitational field, without this limiting or invalidating the results.
5.5.1. Configuration
5.5.1.1 Signal Parameters
For simplicity, the simulated signal is based on transmitting one GPS's DSSS BPSK L1C/A code.
Carrier frequency fcarr = 1575.42 MHz
Chip frequency fc = 1/Tc = 1.023 Mcps. Code length: 1023. Data frequency: no data has been modulated. Code: 1023-chip Gold code as for GPS L1 C/A of PRNs 121 (SBAS satellite).
Synchronisation: The satellite transmits only one code at t0 + btx, where btx is the clock bias of the satellite.
Received carrier to noise density ratio: C/N0 = 50 dBHz
5.5.1.2 Satellite and Propagation Parameters
The satellite is located at zero longitude, zero latitude and around 1630 km altitude. The clock performance is considered similar to that of standard TCXO clocks. The satellite velocity is set to arbitrary values. The currently proposed satellite speed is around 3.7 km/s, while the speed of a satellite at that orbit would be around twice as much. This is considered sufficiently representative for the proof-of-concept.
XYZ ECEF (Earth Centred Earth Fixed) coordinates: (0, 0, 8000000) [m] Vxyz (ECEF): (1000, 2000, 3000) [m/s].
Clock bias: 푏푡푥 = 20 ms 6 Clock drift: 푓푑푡푥 = 1 ppm (1Hz / 10 Hz)
A normal error distribution of variance 1 m2 N(0,1) has been introduced to model signal propagation errors. This simplistic model intends to account the residual ionospheric,
173 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION tropospheric and multipath errors. We know that it is not a fine-grained error model but it seems enough for this section's objectives. It is also assumed that the ground segment can have an available tropospheric and ionospheric real-time correction model and the stations are sufficiently free from multipath. A more refined model including elevation dependent errors and error contributions as that proposed in [2], Chapter 5, is left for future work. The satellite initial positions and velocities are given in an ECEF frame. The simulator only uses ECEF positions.
5.5.1.3 Monitor Station Parameters
We consider 6 monitor stations (M1 to M6) granting a reasonable geometry at the following latitude (º), longitude (º) and height (m) (wrt. WGS84 geoid) positions: (0,0,0), (20, 0, 0), (0, 15, 0), (0, -20, 0), (-15, 0, 0), (10, 10, 0), as shown in Figure 68.
Figure 68 – Snapshot satellite positioning – Satellite and Ground monitor positions (Google Earth) For this test, the monitor clock biases and drifts are considered zero: we can assume that the monitors have good clocks, and any drifts and biases can be estimated to a level that would not degrade the performance. These are the remaining common monitor station parameters:
174
Intermediate Frequency fIF = 1.51 MHz
Sampling Frequency fs = 16.7439 MHz RF Front End Central frequency: 1575.42 MHz
RF Front End Bandwidth: fs /2 Masking Angle = 5º Acquisition frequency step = 500 Hz Acquisition frequency bins = 81
The sampling frequency has been selected taking into account the fact that it should not be commensurate with fc. The effect of commensurate frequencies for snapshot positioning is that they will lead to a 'staircase' correlation peak that degrades the accuracy, as explained in [65]. It is recommended to use a sampling frequency so that
푝 푓 = 푓 (5.22) 푠 푞 푐 where p and q are prime numbers. In our case, p = 15991 and q=997.
The acquisition window length is 15 ms. We assume that the stations are roughly synchronised (Case B above), i.e. they start acquiring the signal at around t0, i.e. the time the signal is expected to arrive. The acquisition search is that presented in section 4.5.2 and follows a parallel code-phase acquisition.
The acquisition search space, which usually ranges between -10 kHz and +10 kHz approx., can be covered with 21 bins being separated by 500-Hz. In our case, the 81 bins are used, covering -40 kHz to +40 kHz. Leaving 10 kHz as a margin for other effects (satellite and receiver clock drifts, receiver velocity), we have +/- 30 kHz for the satellite velocity, which at the employed wavelength, would allow the acquisition of a satellite at a relative velocity of approximately 5700 m/s. While this may not be enough for some LEO satellites, which orbit at a speed around 7 km/s, it is enough for the demonstrator. Enlarging the acquisition search space would make the simulation longer but would not change the results or the conclusions. As the frequency Doppler depends on the wavelength, satellites at other carrier frequencies may require careful analysis leading to a different frequency search space and step width. This is left for further work.
175 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
5.5.2. Simulator Steps
This section describes the process of signal generation, acquisition at the monitors, and satellite PVT computation.
5.5.2.1 Signal Generation
For each satellite-monitor pair, the monitor-to-satellite vector and range rate at t0 is calculated. The theoretical range is generated taking into account the fact that, when the satellite transmits the signal, it is at a different position than at t0, as expressed in Equation (5.21).
The frequency at which the signal is generated emulates the frequency as received by the monitor as per equations (5.3) and (5.4). The simulated range adds a random error following the configured error model.
In general, in order to simulate the digitally sampled signal, the signal generator needs to account for the frequency drift of the monitor, even if set to zero in this experiment.
푓푠,푚 = 푓푠 + 푓푑푚 (5.23) where m is the identifier of the monitor station. With all these parameters, and the signal is generated according to Equation (5.6). It is generated at a higher sampling rate (an x10 multiplication factor is configured in the simulator), and then down-sampled according to the sampling rate of the monitor.
Once the signal is generated, noise is added according to the configured C/N0. For that, the signal power is normalised to 1 Watt, and the noise power is calculated accordingly:
푓 푃 = 푁 푠,푚 (5.24) 푛 0 2
Where 푃푛 is the noise power, and 푁0 is the noise density from the C/N0. The simulator could be evolved to compute 푁0 by knowing the effective temperature from the front-end noise figure following the Friis formula, e.g. from [5], Chapter 6. Once 푃푛 is known, the noise will follow a normal distribution 푁(0, √푃푛).
The generated signal is also filtered to simulate the noise and delay filtering effects. An IIR (Infinite Impulse Response) band-pass Butterworth filter with -3 dBs at both cut-off
176
frequencies and order 10 has been implemented. The cut-off frequencies are calculated depending on the receiver bandwidth configured (see e.g. user configuration in section 5.6.1.4). Note that monitor stations can have wide bandwidths to minimise accuracy loss. In the current configuration, to facilitate the comparison with theoretical results, no filtering has been applied. Unlike end users, monitor stations can have wide bandwidths minimising this effect, so it is not unrealistic to minimise filtering effects.
Figure 69 - Monitor snapshot generation: signal samples for one signal at 6 monitor stations. C/N0 = 70 dBHz. Fs = 16.7439 MHz The steps above are performed for each monitor stations, in order to generate all the signal snapshots as illustrated in Figure 69. This figure shows the signal plus noise in the time domain. A 1-ms fragment of the signal is received by each monitor. C/N0 has been raised to 70 dBHz to raise the signal visible above noise in the time domain.
5.5.3. Signal Acquisition and Parameter Estimation
The signal acquisition process is performed as explained theoretically before and according to the configuration parameters. The satellite reference parameters estimated for each station are the signal delay, frequency, bit sequence and C/N0. Delay and frequency are estimated as
177 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION mentioned before (parallel code-phase acquisition). The bit sequence in this case is known.
14 Concerning the C/N0, it is estimated by the method of moments [65], as follows :
푋퐵 − 푇푃 퐶/푁 = 10푙표푔 ( ) (5.25) 0 10 푇2푃 − 푋 where X is the result of the squared peak, B is the signal bandwidth and T is the integration time (1 ms). There are other standard methods in the literature, as proposed by A.J. Van Dierendonck in Chapter 8 of [3], based on the difference between the non-coherent and coherent averages in the correlation peak. However, for snapshot positioning, and in particular the current experiment, given that averaging is not possible, the method of moments is selected.
5.5.4. Satellite PVT Computation
Based on the range and frequency measurements calculated in the acquisition stage, the satellite PVT can be calculated as per Equation (5.17). Satellite velocity and frequency drift is estimated as per Equation (5.20). The satellite position is not calculated for t0, but for the time the satellite transmitted the signal, t0 + btx . If the position to be reported is the satellite position at t0, then the satellite movement during btx needs to be accounted, as per Equation (5.21).
5.5.5. Results
This section reports the satellite positioning results obtained, over 50 runs. Figure 70 presents the satellite error vector in three dimensions. Figure 71 represents the satellite error in 3D coordinates. The capture below shows the acquisition results from each station, for one of the runs.
** SNAPALL REPORT ** CRLB std. dev. [m]: 4.700
Elevations matrix [º]: SV34 M1 90.00 M2 22.76 M3 33.09 M4 22.61 M5 33.25 M6 35.39
M1 Acquisition . SVID34 peak:10.18; PR Error: -6.21 m; f Error: 7.216 Hz; CN0: 49.42 dBHz M2 Acquisition - SVID34 peak: 8.31; PR Error: 5.48 m; f Error: 60.177 Hz; CN0: 50.26 dBHz M3 Acquisition - SVID34 peak: 7.31; PR Error: -1.23 m; f Error: 2.337 Hz; CN0: 48.12 dBHz M4 Acquisition - SVID34 peak: 8.46; PR Error: 3.13 m; f Error: -20.206 Hz; CN0: 49.00 dBHz M5 Acquisition - SVID34 peak: 9.98; PR Error: 1.92 m; f Error: 48.860 Hz; CN0: 49.88 dBHz M6 Acquisition - SVID34 peak: 5.53; PR Error: -1.18 m; f Error: 31.444 Hz; CN0: 48.52 dBHz
14 The formula in [62] had an error that is corrected in the formula here proposed.
178
Locating Satellite SV01 GDOP: 5.12 PDOP: 4.13 TDOP: 3.03 xDOP: 3.90 ( X, Y, Z, B)[m][s]:( 8000028.98 , -2.23 , 0.70 , 1.999992e-02) ( dX, dY, dZ, dB)[m][s]:( 28.98 , -2.23 , 0.70 , -7.603586e-08) ( VX, VY, VZ, FD)[m/s] :( 1009.77 , 2003.87 , 3001.42 , -1.318053e-04) (dVX,dVY,dVz,dFD)[m/s] :( 9.77 , 3.87 , 1.42 , -1.328053e-04)
One can see that the results are more or less as expected. With a CRLB standard deviation of 4.7 m and a PDOP of 4.13, we can expect an RMS accuracy (assuming no biases, as is the case) around 4.7 * 4.13 = 19.411m. We see that the RMS-3D error obtained is 19.95 m.
Figure 70 – Satellite position 3D error [m] and RMS-3D.
Figure 71 – Satellite position 3D error [m] in XYZ coordinates.
179 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 71 shows a much higher error in the X component. This is natural as the geometry is especially bad in the vertical (or X) axis. The DOP values for the different components are: GDOP = 5.1185; PDOP = 4.1272; XDOP = 3.8970; YDOP = 0.9540; ZDOP = 0.9680; TDOP = 3.0275, which may explain the degradation in this component (XDOP) and in the time (TDOP).
In summary, the results show an accuracy below 20 meters about two thirds of the time. While not great, it is what can be expected from this geometry and signal delay estimation accuracy. Signals with wider bands and using longer integration times will offer a higher accuracy.
5.6. Experimental Results: User Snapshot Positioning Based on Satellite Snapshot Positioning
This section presents the end-user performance of the snapshot generalisation method using four satellites and a wider service area, based on satellites at a higher altitude and more spread-out stations. As mentioned for the one-satellite case, the signals and satellite orbits and velocities analysed are fictitious, but the analysis is considered generic enough to be applicable to other signal and satellites.
5.6.1. Configuration
5.6.1.1 Signal Parameters
Signal parameters are the same as in the previous test. The Gold codes used for the four satellites under test correspond to PRNs 121, 122, 123 and 124.
5.6.1.2 Satellite and Propagation Parameters
The satellite configuration parameters are:
Table 24 - Satellite Parameters
SAT PRN Position at t0 [X;Y;Z], Velocity at t0 Clock bias Clock drift at t0 [s/s] Initial ECEF [m] [VX;VY;VZ], at t0 [s/s] Orbital ECEF [m/s] Radius [m] 1 121 [18000e3; 0; 0] [0; 1000; 2000] 5e-3 1e-7 (0.1 ppm) 7000e3
2 122 [1.5588e7; -9e6; 0] [2000 ; 0 ; 1000] 8e-3 -1e-7 (-0.1 ppm) 18000e3
3 123 [1.5588e7; 9e6; 0] [1000 ; 2000 ; 0] -6e-3 1e-8 (-0.01 ppm) 12000e3
4 124 [1.039e7; 1.039e7; 9.237e6] [-1000 ; -2000 ; 0] -4e-3 1e-8 (0.01 ppm) 12000e3
180
The Initial Orbital Radius parameter represents the initial height at which the least-squares position estimator starts. The same normal error distribution of variance 1 m2, denoted as N(0,1) as before has been used.
5.6.1.3 Monitor Station Parameters
6 Monitor stations (M1 to M6) have also been used in this case, at the following positions (lat(º), long(º), h(m wrt. WGS84)): (0, 0, 0), (45, 0, 0), (0, 45, 0), (0,-45, 0), (-45, 0, 0), (20, 20, 0), as shown in Figure 72.
These are the common monitor station parameters:
Intermediate Frequency fIF = 3.5 MHz
Sampling Frequency fs = 16.7439 MHz RF Front End Central frequency: 1575.42 MHz
RF Front End Bandwidth: fs /2 Masking Angle = 5º Acquisition frequency step = 500 Hz Acquisition frequency bins = 81
Figure 72 – Snapshot ground segment, including 6 stations and a test user. Here are some additional comments on the monitor station parameters:
181 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Stations 2 to 5 are in the same plane. A solution based on measurements from these four stations would lead to a rank-deficient matrix. This is supposed to be mitigated by stations 1 and 6. Nevertheless, optimum geometry solutions have not been studied yet. For the moment, the biases and drifts are set to zero. It can be realistically assumed that monitor stations can have good clocks (or a GNSS receiver) and time errors would be in the order of the nanosecond, or below.
5.6.1.4 User Receiver Parameters
The user receiver parameters are:
Intermediate Frequency fIF = 3.5 MHz
Sampling Frequency fs = 16.7439 MHz RF Front End Central frequency: 1575.42 MHz RF Front End Bandwidth (single-sided): 3 MHz Masking Angle = 5º Acquisition frequency step: 500 Hz Acquisition frequency bins: 81
User clock bias: brx = 3 ms
User clock frequency drift: fdrx = 2 ppm (2 cycles per million cycles)
The frequency plan has been slightly updated with respect to the previous test: The intermediate frequency is 3.5 MHz, allowing testing the effect of filtering in the system. Figure 73 shows the full system, including the four satellites, the 6 monitor stations, and the user.
182
Figure 73 – Ground segment, space segment, and user segment Table 25 shows the elevations of each satellite with respect to each station. Some satellites are below the horizon but the system geometry ensures that all satellites are seen by at least four stations.
Table 25 - satellite elevations (º)
Elevations SAT1 SAT2 SAT3 SAT4
M1 90º 45.66º 45.66º 16.10º
M2 26.59º 18.13º 18.13º 35.79º
M3 26.51º -5.65º 67.06º 42.00º
M4 26.51º 67.06º -5.65º -20.17º
M5 26.59º 18.13º 18.13º -17.77º
M6 48.44º 17.41º 56.49º 51.25º
Usr 58.15º 24.23º 58.15º 40.77º
183 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
5.6.2. Simulator Steps
The simulation steps from signal generation to satellite PVT computation have been described in the previous section. We assume here that the satellite reference parameters (position, velocity, bias, drift, sequence) have been computed for the four satellites. Therefore, the only remaining step is the user PVT computation.
Once the satellite positions, velocities and clock parameters are known, and the user has stored a snapshot with the satellite measurements, there are no particularities in estimating the user position. The simulator is estimating the user position through standard least squares following equations (5.16) and (5.17).
5.6.3. Results
This section presents the user positioning results, obtained over 30 runs. Each run took approximately 3 mins with Matlab running in an Intel i7-3630QM CPU @ 2.4 GHz, in Windows 8 at x64 bits. The Matlab code was running in debugging mode to output figures and results and was not optimised. Optimised codes in other languages and faster parallelised platforms may allow running the method instantaneously (i.e. with an execution time comparable to the snapshot duration). As an example, the following capture shows the main intermediate results of one of the 30 runs.
Table 26 – User positioning through general snapshot satellite system results
** SNAPALL REPORT ** CRLB std. dev. [m]: 4.700
Elevations matrix [º]: SV34 SV35 SV36 SV37 M1 90.00 45.66 45.66 16.10 M2 26.59 18.13 18.13 35.79 M3 26.51 -5.65 67.06 42.00 M4 26.51 67.06 -5.65 -20.17 M5 26.59 18.13 18.13 -17.77 M6 48.44 17.41 56.49 51.25
M1 Acquisition SVID34 peak: 5.49; PR Error: 8.44 m; f Error: 47.242 Hz; CN0: 49.10 dBHz SVID35 peak: 6.83; PR Error: 4.47 m; f Error: -20.401 Hz; CN0: 48.35 dBHz SVID36 peak:13.82; PR Error: 6.13 m; f Error: -15.073 Hz; CN0: 50.69 dBHz SVID37 peak:12.19; PR Error: 5.40 m; f Error: 14.127 Hz; CN0: 50.91 dBHz
M2 Acquisition SVID34 peak: 9.96; PR Error: 3.99 m; f Error: 3.588 Hz; CN0: 49.79 dBHz SVID35 peak: 8.27; PR Error: 3.91 m; f Error: 70.630 Hz; CN0: 49.17 dBHz SVID36 peak: 8.34; PR Error: 0.88 m; f Error: 60.832 Hz; CN0: 49.47 dBHz SVID37 peak:10.08; PR Error: -4.21 m; f Error: 0.465 Hz; CN0: 49.92 dBHz
M3 Acquisition SVID34 peak:15.52; PR Error: -9.58 m; f Error: -14.502 Hz; CN0: 50.59 dBHz . SVID36 peak:10.91; PR Error: 5.08 m; f Error: -57.849 Hz; CN0: 50.16 dBHz SVID37 peak: 9.58; PR Error: 1.11 m; f Error: -30.153 Hz; CN0: 49.90 dBHz
M4 Acquisition SVID34 peak:11.25; PR Error: 10.78 m; f Error: 22.119 Hz; CN0: 50.65 dBHz SVID35 peak:11.13; PR Error: -1.72 m; f Error: -65.754 Hz; CN0: 49.79 dBHz . .
M5 Acquisition SVID34 peak:11.61; PR Error: 3.68 m; f Error: 4.029 Hz; CN0: 49.74 dBHz SVID35 peak:13.28; PR Error: -1.68 m; f Error: -10.617 Hz; CN0: 51.13 dBHz SVID36 peak: 9.32; PR Error: 0.88 m; f Error: 9.734 Hz; CN0: 49.22 dBHz .
184
M6 Acquisition SVID34 peak: 7.52; PR Error: -6.68 m; f Error: -92.201 Hz; CN0: 48.93 dBHz SVID35 peak:10.73; PR Error: -1.90 m; f Error: -67.462 Hz; CN0: 49.84 dBHz SVID36 peak: 7.23; PR Error: -2.31 m; f Error: 46.904 Hz; CN0: 48.61 dBHz SVID37 peak:11.48; PR Error: 8.23 m; f Error: 81.179 Hz; CN0: 50.13 dBHz
Locating Satellite SV01 GDOP: 29.52 PDOP: 21.39 TDOP: 20.34 xDOP: 21.17 ( X, Y, Z, B)[m][s]:( 17999905.36 , -35.43 , -3.11 , 5.000295e-03) ( dX, dY, dZ, dB)[m][s]:( -94.64 , -35.43 , -3.11 , 2.952998e-07) ( VX, VY, VZ, FD)[m/s] :( -79.53 , 978.58 , 1988.74 , 1.970120e-05) (dVX,dVY,dVz,dFD)[m/s] :( -79.53 , -21.42 , -11.26 , 1.960120e-05)
Locating Satellite SV02 GDOP: 45.93 PDOP: 33.13 TDOP: 31.81 xDOP: 26.88 ( X, Y, Z, B)[m][s]:( 15588408.95 , -8999960.37 , 6.04 , 8.000191e-03) ( dX, dY, dZ, dB)[m][s]:( -48.31 , 39.63 , 6.04 , 1.910498e-07) ( VX, VY, VZ, FD)[m/s] :( 2293.01 , -200.19 , 1015.91 , -1.306621e-04) (dVX,dVY,dVz,dFD)[m/s] :( 293.01 , -200.19 , 15.91 , -1.305621e-04)
Locating Satellite SV03 GDOP: 41.18 PDOP: 29.71 TDOP: 28.52 xDOP: 24.02 ( X, Y, Z, B)[m][s]:( 15588407.30 , 8999966.75 , -4.47 , -5.999810e-03) ( dX, dY, dZ, dB)[m][s]:( -49.97 , -33.25 , -4.47 , 1.904129e-07) ( VX, VY, VZ, FD)[m/s] :( 1189.74 , 2094.40 , 23.53 , -8.753485e-05) (dVX,dVY,dVz,dFD)[m/s] :( 189.74 , 94.40 , 23.53 , -8.754485e-05)
Locating Satellite SV04 GDOP: 66.02 PDOP: 47.53 TDOP: 45.82 xDOP: 25.00 ( X, Y, Z, B)[m][s]:( 10392184.08 , 10392112.90 , 9237422.74 , -3.999068e-03) ( dX, dY, dZ, dB)[m][s]:( -120.77 , -191.94 , -181.57 , 9.316991e-07) ( VX, VY, VZ, FD)[m/s] :( -1306.03 , -2433.64 , -361.21 , 2.631344e-04) (dVX,dVY,dVz,dFD)[m/s] :( -306.03 , -433.64 , -361.21 , 2.631244e-04)
** USER SOLUTION ** SVID34 peak: 7.72; f Error: -30.512 Hz; CN0: 50.25 dBHz SVID35 peak: 7.80; f Error: -18.058 Hz; CN0: 50.56 dBHz SVID36 peak:11.24; f Error: 39.693 Hz; CN0: 51.37 dBHz SVID37 peak: 7.83; f Error: -59.058 Hz; CN0: 50.72 dBHz ( X, Y, Z, B)[m] :( 5952245.43 , 1594889.73 , 1640132.95 , -1.268617e-01) ( dX, dY, dZ, dB)[m] :( 27.84 , -2.16 , 32.81 , -1.278617e-01)
The results show that DOP values for the satellite positioning are very high (GDOPs are between 29.52 and 66.02). This is because geometry of the monitor stations is much worse than for standard satellite positioning, especially for satellites at high elevations, as most lines of sight are concentrated over the same area (the Earth) with respect to the total satellite visibility. Geometry is much worse in this case compared to the 1-satellite test, as in the latter the satellite was at a lower height. Even if the signal delay estimation accuracy is not far from the CRLB of 4.7 m (std. dev.), the satellite position errors are of several tens of meters in general, and this translates in the user position error.
Figure 74 and Figure 75 show the user accuracy results of 30 runs. RMS-3D of 73.2 m and RMS-2D of 42.8 m reflect the accuracy degradation due to the suboptimal geometry. The elliptical shape of the scatter plot in Figure 75 shows a high covariance in the XY components, which reflects this suboptimal satellite geometry, which translates in further accuracy degradation.
185 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Figure 74 – User horizontal (2D) and 3D position error and RMS error
Figure 75 – User horizontal position error (X=East; Y=North) The results show that there is room for accuracy optimisation. Nevertheless, this accuracy may be enough for certain applications, especially if the service is provided indoors or increases localisation resilience. Anyway, more realistic results can be obtained when analysing more in detail the signals of other non-GNSS constellations, which is left for future
186
work. As mentioned at the beginning of the chapter, the fact that higher C/N0, similar-to- GNSS or wider bandwidths are used for this signals, and the fact that only 1 ms integration time has been tested, suggest that meter-level results can be obtained. Also, taking into account that only four satellites have been used, while there may be hundreds usable non- GNSS satellites, one can assume that geometrical DOP can be also decreased.
That being said, the purpose of developing an end-to-end Matlab simulator of the proposed positioning method as a proof-of-concept has been fulfilled. This simulator can be easily reconfigured and enhanced to study the performance of other satellite-to-monitor geometries, signal frequencies, bandwidths and bitrates, RF properties at the stations and user receiver, and so on. The error models can be enhanced to model more realistic errors, for example, for better modelling multipath errors at user level.
5.7. Conclusions
This chapter has presented a satellite positioning method based on a snapshot ground segment, which provides instantaneous satellite reference parameters (position, velocity, clock bias, clock drift, bit sequence) to a user receiver. The method may be applied to present and future non-GNSS satellites transmitting signals with the adequate properties: wide- enough bandwidth, enough power and sufficiently long integration times. Together with ranging accuracy, satellite-monitor geometry is the other driver for positioning accuracy.
A signal model has been proposed based on continuous or pulsed BPSK-like signals. An error model is proposed as well, including signal generation, reception and propagation errors, with a focus on the first two. First, the method for calculating the position of a satellite has been evaluated with one-millisecond pulses of GPS-like signals. The satellite clock has been modelled with a bias and a drift of a medium quality oscillator, at an orbit with radius of 8000 kilometres. 3D-RMS errors obtained in the satellite position calculation are below 20 metres, which is in line with the expected values according to the geometry and the CRLB, especially given the very short integration times (one millisecond).
Finally, the whole system, including satellite, ground and user segments, is simulated. A user position horizontal error of around 40 metres RMS-2D has been obtained, using an almost arbitrary 6-station ground network and four satellites at orbits at around 18.000 km radius. The position accuracy is highly degraded by the satellite-to-monitor and satellite-to-user geometry. Ranging accuracy based on CRLB shows that much higher accuracies could be
187 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION obtained. In any case, no major hurdles have been found to implement a snapshot-based positioning system using satellites with unstable clocks and non-GNSS signals.
188
Chapter 6. Conclusions and Further Work
This thesis has presented some concepts, frameworks, models, experiments, and results on satellite navigation authentication and snapshot techniques.
On satellite navigation authentication, this thesis proposes some concepts to improve authentication performance. With the proposed approaches, which are based on a TESLA protocol using a single key chain, cross-authentication, and reduced key and MAC lengths, authentication bits can be reduced to less than two hundred, improving availability and robustness. Users can then authenticate navigation data without performance loss. The thesis presents a specific implementation proposal for the Galileo I/NAV message which allows an average time between authentications of 5 seconds, at 20 bps, out of which 4 bps are devoted to a root key certificate and 16 bps to MACs and keys. The signal is unpredictable every 1.6 seconds, making it suitable for A-GNSS or snapshot users that require to be protected against replay attacks. Anti-replay capabilities based on the first samples of each unpredictable symbol are also characterised.
The thesis then presents the "cold snapshot" method. This method allows a position to be calculated based on a digital snapshot without any time or position reference parameters. The method is based on using the instantaneous Doppler equations with an additional 'coarse time' unknown, which can be as high as several hours, depending on the satellite geometry and constellations used. The "cold snapshot" method is algebraically described and characterized with real data snapshots in a snapshot software receiver. Through several iterations, it is proven that time uncertainties of around a month can be solved almost instantaneously, obtaining an accuracy similar to that of standard snapshot positioning.
Another research area of the thesis is the generalization of snapshot techniques to non-GNSS satellites. This method may serve to calculate snapshot user positioning based on other satellites that may transmit more powerful and wider bandwidth signals for communications
189 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION than that used for GNSS, thus improving resilience and indoor localization availability. In order to test this concept, an end-to-end simulator has been developed, including space, ground, and user segments. The results obtained in a use case with six stations and four satellites show user position errors in the order of tens of metres. These errors can be significantly reduced by improving the geometry and the signal processing features. They are, however, sufficient to validate the concept at this stage. The work performed proves that such end-to-end snapshot architectures are feasible.
The thesis finalizes with a short appendix (Appendix D) establishing some concepts and theoretical basis to authenticate snapshots, which is equivalent to authenticating signals from receiver start-up. The proposed methods are based on signal unpredictability, as that offered by the NMA scheme proposed before, a trusted and accurate clock reference, and the introduction of geometrical constraints such as height from a digital model.
6.1. Further Work
This section presents the further work in the different research areas of this thesis. As the research areas cover different topics, it is presented separately for each chapter.
6.1.1. GNSS Authentication
Areas of further work in GNSS authentication in general and NMA in particular are:
The analysis of how the receiver can deal with data-authenticated, replay-authenticated, and non-authenticated signals, and other sensors, and derive from those an overall confidence level for position authenticity. The proposed concept extension to spreading code-based measures, as the quick transmission of keys also allows low TBAs in this case. The implementation of TESLA- based NMA+SCE can be a subject of further research. Sensitivity analyses for antireplay protection, including hypothesis testing versus missed
detection and false alarm probabilities for different NU and NC values and under different spoofing conditions. To further understand the performance in urban environments and optimise the algorithms to place MACs throughout the MAC-K sections of a subframe, Monte Carlo simulations using realistic reception probabilities and LMS models can be performed.
190
6.1.2. Cold Snapshot
Further experiments may be conducted on the following subjects:
Application of the algorithm to multi-GNSS receivers, in which the mentioned orbital repeatability of GPS would be mitigated by other constellations. In addition, other methods to cope with non-linearity to get a one-shot fix without needing several iterations for periods longer than some hours may improve the performance of the method. The focus of the research was not on obtaining the highest accuracy from the measurements. Longer snapshots, including open loop and closed loop techniques, or any other advanced signal processing techniques, may improve further snapshot positioning performance. High accuracy Doppler measurements could be obtained by allowing stable carrier phase tracking for a given time, reducing the Doppler error to the carrier frequency measurement error. Testing and tuning of the algorithm for dynamic users and in degraded environments.
6.1.3. Snapshot Generalisation
Further work proposed to continue the research in this chapter includes:
Use of Weighted Least Squares (WLS) or Receiver Autonomous Integrity Monitoring (RAIM) methods to detect inaccurate measurements, both in the satellite positioning as in the user positioning stages. Sensitivity analyses on the performance impact from satellite clock biases and drifts, and adding more refined satellite clock models as proposed in [95] and [96]. Analyse real non-GNSS satellites and signals in more depth and configure the simulator accordingly to study their performance. Study the effect of different receiver hardware biases in case signals at different carrier frequencies are used for the same snapshot position. Study the case in which the ground segment can perform continuous tracking of the satellite signals, to reduce the error from the satellite snapshot positioning methods, even if the snapshot techniques are applied at user level. Add more refined ionospheric, tropospheric and multipath propagation error models. Study in more detail the signal acquisition process with non-GNSS signals: impact of using highly different carriers in Doppler measurements, cross correlation with other signals, etc.
191 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Simulate realistic satellite-monitor geometries, taking into account realistic satellite orbits and potential monitor locations.
6.1.4. Snapshot Authentication
In order to complement Appendix D, further work can be conducted in these subjects:
Experimentation of the proposed authentication algorithms, and improvements thereof derived. Development of a theoretical model to define the missed detection and false alert probabilities for different algorithms under different cases, including more realistic error models. Combination of signal-related authentication measures with position-related authentication measures towards fully authenticated snapshot localization.
192
LITERATURE LIST
[1] J. Williams, From Sails to Satellites: Origin and Development of Navigational Science, Oxford University Press, 1992.
[2] P. Misra and P. Enge, Global Positioning System: Signals, Measurements and Performance (Revised Second Edition), Ganga-Jamuna Press, 2010.
[3] B. W. Parkinson and J. J. Spilker, Global Positioning System: Theory & Applications (Volume One), 1st Edition ed., American Institute of Aeronautics and Aeronautics, 1996.
[4] J. Nurmi, E. S. Lohan, S. Sand and H. Hurskainen, Galileo Positioning Technology, Springer, 2014.
[5] F. van Diggelen, A-GPS: Assisted GPS, GNSS, and SBAS, Artech House, 2009.
[6] E. Kaplan and C. Hegarty, Understanding GPS Principles and Applications, Artech House Inc., 2006.
[7] A. J. Viterbi, “Spread Spectrum Communications - Myths and Realities,” IEEE Communications Magazine, 1979.
[8] J. Betz, “Binary Offset Carrier Modulations for Radionavigation,” NAVIGATION: Journal of The Institute of Navigation , vol. 48, no. 4, 2002.
[9] S. Wallner, “Navipedia,” [Online]. Available: http://www.navipedia.net/index.php/GNSS_signal. [Accessed April 2015].
193
SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
[10] J. Á. Á. Rodríguez, On Generalized Signal Waveforms for Satellite Navigation - PhD Dissertation, UNIVERSITY FAF MUNICH, 2008.
[11] The US Government, “GPS Interface Specification IS-GPS-200,” 2014.
[12] European Union, “OSSISICD: Open Service Signal In Space Interface Control Document, Issue 1.1,” September 2010.
[13] K. Borre, D. M. Akos, N. Bertelsen, P. Rinder and S. H. Jensen, A Software-Defined GPS and Galileo Receiver: Single-Frequency Approach, Birkhäuser, 2007.
[14] F. Piper and S. Murphy, Cryptography – A Very Short Introduction, Oxford University Press, 2002.
[15] N. Ferguson, B. Schneier and T. Kohno, Cryptography Engineering - Design Principles and Practical Applications, Wiley & Sons, 2010.
[16] S. Singh, The Code Book: Science of Secrecy from Ancient Egypt to Quantum Cryptography, Anchor Books, 2000.
[17] J. Daemen and V. Rijmen, “AES Proposal: Rijndael,” National Institute of Standards and Technology, 2001.
[18] W. Diffie and M. E. Hellman, “New Directions in Cryptography,” IEEE Transactions on Information Theory, Vols. IT-22, pp. 644-654, 1976.
[19] A. Menezes, P. Van Oorschot and S. Vanstone, Handbook of Applied Cryptography, CRC Press, Inc., 1997.
[20] L. Scott, “Anti-Spoofing & Authenticated Signal Architectures for Civil Navigation Systems,” ION GPS, 2003.
[21] O. Pozzobon, G. Gamba, M. Canale and S. Fantinato, “Supersonic GNSS Authentication Codes,” in Proceedings of the 27th International Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS+ 2014), Tampa, Florida, 2014.
194 LITERATURE LIST
[22] C. Wullems, O. Pozzobon and K. Kubik, “Signal Authentication and Integrity Schemes for Next Generation Global Navigation Satellite Systems,” Proceedings of the European Navigation Conference, 2005.
[23] K. Wesson, M. Rothlisberger and T. Humphreys, “Practical Cryptographic Civil GPS Signal Authentication,” The Journal of the Institute of Navigation, February 2012.
[24] John A. Volpe National Transportation Systems Cent, “Vulnerability Assessment of the Transport Infrastructure Relying on the Global Positioning System,” U.S. DoT, 2001.
[25] T. Humphreys, “Detection Strategy for Cryptographic GNSS Anti-Spoofing,” in IEEE Transactions on Aerospace and Electronic Systems , 2013.
[26] I. Fernández-Hernández, J. Simón, R. Blasi, C. Payne, T. Miquel and J. P. Boyero, “The Galileo Commercial Service: Current Status and Prospects,” Coordinates, pp. 18-25, July 2014.
[27] I. Fernandez-Hernandez, I. Rodríguez, G. Tobías, J. D. Calle, E. Carbonell, G. Seco- Granados, J. Simón and R. Blasi, “Testing GNSS High Accuracy and Authentication - Galileo’s Commercial Service,” Inside GNSS, pp. 37-48, Jan-Feb 2015.
[28] O. Pozzobon, “Keeping the spoofs out - Signal Authentication Services for future GNSS,” InsideGNSS, 2011.
[29] D. Calle, E. Carbonell, I. Rodríguez, G. Tobías, E. Göhler, O. Pozzobon, M. Cannale and I. Fernández-Hernández, “Galileo Commercial Service from the Early Definition to the Proof-Of-Concept,” in Proceedings of the ION GNSS+ 2014, Tampa, FL, 2014.
[30] “ISO/IEC 27000,” Interational Standards Organisation, 2014.
[31] I. S. Organisation, “ISO/IEC 15408-1:2009,” 2009.
[32] SSI, “ssi.gouv.fr,” [Online]. Available: http://www.ssi.gouv.fr. [Accessed Dec 2013].
[33] Z. Yazar, “A qualitative risk analysis and management tool – CRAMM,” SANS Institute, 2002.
195 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
[34] G. W. Hein, F. Kneissl, J. A. Avila-Rodriguez and S. Wallner, “Authenticating GNSS Proofs against Spoofs,” Inside GNSS, 2007.
[35] S. Lo, D. De Lorenzo, P. Enge, D. Akos and P. Bradley, “Signal Authentication: A Secure Civil GNSS for Today,” InsideGNSS, no. September-October 2009, 2009.
[36] C. Günther, “A Survey of Spoofing and Counter-Measures,” NAVIGATION, Journal of The Institute of Navigation, vol. 61, no. 3, Fall 2014, pp. 159-177., 2014.
[37] D. Lu, R. Wu, P. Li and Z. Su, “GPS smart jammer suppressin algorithm based on spatial APES,” in International Symposium on Intelligent Signal Processing and Communication Systems, 2007. ISPACS. , 2007.
[38] M. Kuhn, “An Asymmetric Security Mechanism for Navigation Signals,” Proceedings of the Information Hiding Workshop, 2004.
[39] A. Kerns, D. Shepard, J. Bhatti and T. Humphreys, “Unmanned Aircraft Capture and Control Via GPS Spoofing,” Journal of Field Robotics, pp. 617-636, 2014.
[40] A. J. Kerns, K. Wessons and T. Humphreys, “A Blueprint for Civil GPS Navigation Message Authentication,” in Proceedings of Position, Location and Navigation Symposium, Monterey, 2014.
[41] T. Humphreys, “UAVs Vulnerable to Civil GPS Spoofing,” Inside GNSS, 2012.
[42] S. Lo and P. Enge, “Aviation Augmentation System Broadcasts,” IEEE/ION Position Location and Navigation Symposium (PLANS), 2010.
[43] D. Qiu, “Security From Location (PhD Dissertation),” Stanford University, 2009.
[44] G. T. Becker, S. Lo, D. D. Lorenzo, D. Qiu, C. Paar and P. Enge, “Efficient authentication mechanisms for navigation systems – a radio-navigation case study,” in ION GNSS, Savannah, 2009.
[45] I. Fernández Hernández, “Authentication: Design Parameters and Service Concepts,” Proceedings of the European Navigation Conference, 2014.
196 LITERATURE LIST
[46] A. Perrig, R. Canetti, J. D. Tygar and D. Song, “The TESLA Broadcast Authentication Protocol,” CryptoBytes, 2002.
[47] I. Fernandez-Hernandez, V. Rijmen, G. Seco-Granados, J. Simón and I. Rodríguez, “Design Drivers, Solutions and Robustness Assessment of Navigation Message Authentication for the Galileo Open Service,” in ION GNSS+ 2014, 2014.
[48] J. T. Curran, M. Paonni and J. Bishop, “Securing the Open-Service: A Candidate Navigation Message Authentication Scheme for Galileo E1 OS,” in European Navigation Conference ENC 2014, Rotterdam, 2014.
[49] National Institute of Standards and Technology, “FIPS PUB 198-1: The Keyed-Hash Message Authentication Code (HMAC),” 2008.
[50] International Organization for Standardization, “ISO/IEC 9797-1:2011: Information technology - Security techniques - Message Authentication Codes (MACs) - Part 1: Mechanisms using a block cipher,” 2011.
[51] I. Rodríguez, G. Tobías, D. Calle, J. M. Martín, O. Pozzobon, M. Canale, D. Maharaj, P. Walker, E. Göhler, P. Toor and I. Fernández, “Preparing for the Galileo Commercial Service – Proof of Concept and Demonstrator Development,” in Proceedings of the ION GNSS+ 2014, Tampa, Florida, 2014.
[52] A. K. Lenstra, “Key Lengths, contribution to The Handbook of Information Security,” 2004.
[53] ECRYPT, “Yearly report on Algorithms and Keysizes,” 2012.
[54] ENISA, “Algorithms, Key Sizes and Parameters Report - recommendations,” 2013.
[55] National Institute of Standards and Technology, “FIPS PUB 180-4: Secure Hash Standard (SHS),” 2012.
[56] National Institute of Standards and Technology, “DRAFT FIPS PUB 202: SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions,” 2014.
197 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
[57] J. Guilford, K. Yap and V. Gopal, “Fast SHA-256 Implementations on Intel Architecture Processors,” IA Architects, 2012.
[58] Crypto++, “Crypto++ 5.6.0 Benchmarks,” [Online]. Available: http://www.cryptopp.com/benchmarks.html. [Accessed April 2015].
[59] A. Jahn, H. Bischl and G. Heib, “Channel Characterization for Spread Spectrum Satellite,” in IEEE 4th International Symposium on Spread Spectrum Techniques and Applications Proceedings, Volume 3. pp. 1221-1226., 1996.
[60] Trimble, “Planning Online Tool,” Trimble, [Online]. Available: http://www.trimble.com/gnssplanningonline. [Accessed March 2015].
[61] A. Goldsmith, “Wireless Communications,” Cambridge University Press, 2005.
[62] A. J. Viterbi, “Error bounds for convolutional codes and asymptotically optimum decoding algorithm,” IEEE Trans. Inform. Theory, p. 260–269, 1967.
[63] A. J. Viterbi, CDMA: Principles of Spread Spectrum Communication, Addison-Wesley Publishing Company, 1995.
[64] B. Peterson, R. Hartnett and G. Ottman, “GPS Receiver Structures for the Urban Canyon,” Palm Springs, CA, 1995.
[65] G. López-Risueño and G. Seco-Granados, “Measurement and Processing of Indoor GPS Signals Using a One-Shot Software Receiver,” in 2nd ESA Workshop on Satellite Navigation User Equipment Technologies , 2004.
[66] D. Dötterböck and B. Eissfeller, “A GPS/Galileo Software Snap-Shot Receiver for Mobile Phones,” in Proceedings of the IAIN 2009 World Congress, Stockholm, Sweden., 2009.
[67] O. Badia-Solé and T. Iacobescu-Ioan, GPS Snapshot Techniques, Aalborg: Aalborg University, Danish GPS Center, 2010.
[68] H. Chen, W. H.-S., C. Y-T. and F.-R. Chang, “A new coarse-time GPS positioning
198 LITERATURE LIST
algorithm using combined Doppler and code-phase measurements,” vol. 18, no. 4, 2013.
[69] F. van Diggelen, “Method and Apparatus for Time-free Processing of GPS Signals”. U.S. Patent 6417801, November 2000.
[70] K. Borre and G. Strang, Algorithms for Global Positioning, Wellesley-Cambridge Press , 2012.
[71] C. Goad and L. Goodman, “A Modified Tropospheric Refraction Correction Model,” in American Geophysical Union Annual Fall Meeting, San Francisco, 1974.
[72] J. Klobuchar, “Ionospheric Time-Delay Algorithms for Single-Frequency GPS Users,” IEEE Transactions on Aerospace and Electronic Systems, pp. pp. 325-331., 1987.
[73] F. van Diggelen, “GPS Accuracy: Lies, Damn Lies, and Statistics,” GPS World, 1998.
[74] J. Foust, 2015. [Online]. Available: http://www.thespacereview.com/article/2716/1.
[75] “Union of Concerned Scientists - UCS Satellite Database,” 2015. [Online]. Available: http://www.ucsusa.org/nuclear_weapons_and_global_security/solutions/space- weapons/ucs-satellite-database.html.
[76] S. Blumenthal, “satmagazine,” 2010. [Online]. Available: http://www.satmagazine.com/story.php?number=281305822.
[77] R. Barnett, “O3b – A different approach to Ka-band satellite system design and spectrum sharing,” O3b Networks, Almaty, Kazakhstan, 2012.
[78] L. Schiff and A. Chockalingam, “Design and system operation of GlobalstarTM versus IS-95 CDMA – similarities and differences,” Wireless Networks (6), p. 47–57, 2000.
[79] M. A. Jabbar, “Multi-Link Iridium Satellite Data Communication System,” Hyderabad, India, 2001.
[80] S. Pratt, R. Raines, C. Fossa and M. Temple, “An Operational and Performance
199 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Overview of the IRIDIUM Low Earth Orbit Satellite System,” IEEE Communications Surveys, 1999.
[81] D. Whelan, G. Gutt and P. Enge, “BTL, an Indoor Capable Time Transfer and Geolocation System,” Boeing, 2011.
[82] “Globalstar - Position Location,” [Online]. Available: www.globalstar.com/en/index.php?cid?1450. [Accessed 2015].
[83] N. Levanon, “Instant Active Positioning with One LEO Satellite,” Journal of the Institute of Navigation, vol. 46, no. 2, pp. 87-96, 1999.
[84] M. Joerger, J. Neale and B. Pervan, “Iridium/GPS Carrier Phase Positioning and Fault Detection Over Wide Areas”.
[85] M. Joerger, L. Gratton, B. Pervan and C. E. Cohen, “Analysis of Iridium-Augmented GPS for Floating Carrier Phase Positioning,” Journal of the Institute of Navigation, vol. 57, no. 2, pp. 137-160, 2010.
[86] D. Qiu, D. d. Lorenzo and T. Bhattacharya, “Indoor Geo-Location with Cellular RF Pattern Matching and LEO Communication Satellite Signals,” in International Technical Meeting of the Institute of Navigation, San Diego, California, 2013.
[87] M. Rabinowitz, B. Parkinson and J. Spilker, “Some Capabilities of a Joint GPS-LEO Navigation System,” in ION GPS 2000, Salt Lake City, UT, 2000.
[88] M. Toledo, Y. Capelle, G. Seco, A. Mark, I. Fernández, D. Kubrak, M. Monnerat, J. Salcedo, J. Vicario and D. Jiménez, “DINGPOS: Indoor Navigation Demonstration Platform,” in ENC 2008, 2008.
[89] S. M. Kay, Fundamentals of Statistical Signal Processing: Estimation Theory, Prentice Hall, 1993.
[90] U. Mengali and A. N. D'Andrea, Synchronization Techniques for Digital Receivers, Plenum Press, 1997.
200 LITERATURE LIST
[91] N. B. Delgado, “Signal Processing Techniques in Modern Multi-Constellation GNSS Receivers (PhD Thesis),” UNIVERSIDADE TECNICA DE LISBOA - INSTITUTO SUPERIOR TECNICO, 2011.
[92] G. Shen, R. Zetik and R. S. Thomä, “Performance Comparison of TOA and TDOA Based Location Estimation Algorithms in LOS Environment,” in PROCEEDINGS OF THE 5th WORKSHOP ON POSITIONING, NAVIGATION AND COMMUNICATION 2008 (WPNC’08), 2008.
[93] J.-Y. Do, M. Rabinowitz and P. Enge, “Performance of TOA and TDOA in a Non- homogeneous Transmitter Network Combining GPS and Terrestrial Signals,” in Proceedings of the 2006 National Technical Meeting of the Institute of Navigation, PP 642-649, Monterey, CA, 2010.
[94] “N2YO,” [Online]. Available: http://www.n2yo.com/satellites/. [Accessed 2015].
[95] R. G. Brown and P. Y. C. Hwang, Introduction to Random Signals and Applied Kalman Filtering. Third Edition, John Wiley & Sons, Inc., 1997.
[96] T. S. Bruggemann, D. G. Greer and R. Walker, “Chip Scale Atomic Clocks: Benefits to Airborne GNSS Navigation Performance,” in Proceedings International Global Navigation Satellite Systems Society, Holiday Inn Surfers Paradise, Australia, 2006.
[97] National Institute of Standards and Technology, “FIPS PUB 186-3: Digital Signature Standard (DSS),” 2009.
[98] H. Krawczyk, M. Bellare and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” Network Working Group, 1997.
[99] National Institute of Standards and Technology, “NIST Special Publication 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication,” 2004.
[100] International Organization for Standardization, “ISO/IEC 9796-3. Information technology – Security techniques – Digital signatures giving message recovery – Part 3:
201 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Discrete logarithm based mechanisms.,” 2006.
[101] International Organization for Standardization, “ISO/IEC 14888-3: Information technology - Security techniques - Digital signatures with appendix - Part 3: Discrete logarithm based mechanisms - Amendment 1,” 2009.
[102] Russian Institute of Space Device Engineering, “Glonass Interface Control Document - Navigational Radiosignal In Bands L1, L2 (Edition 5.1),” 2008.
[103] China Satellite Navigation Office, “BeiDou Navigation Satellite System Signal In Space - Interface Control Document - Open Service Signal B1I (Version 1.0),” 2012.
[104] “Temperature Compensated Crystal Oscillator (TCXO / VCTCXO),” Pericom, [Online]. Available: https://www.pericom.com/products/crystal-and-crystal- oscillator/tcxo-vctcxo/. [Accessed April 2015].
[105] J. Eidson, “IEEE-1588 Standard Version 2 - A Tutorial,” Agilent Technologies, 2006.
[106] L. Scott, “Proof of Location; Verifying Physical Space in a Virtual Space,” 2012.
[107] M. Weiss, “Telecom Requirements for Time and Frequency Synchronisation”.
[108] I. Fernández-Hernández, J. Caro-Ramón, M. Toledo-López, M. A. Martínez-Olagüe and M. Azaola-Saenz, “Method for map matching with guaranteed integrity”. Patent US8032299 B2, 2008.
[109] G. Strang and K. Borre, Linear Algebra, Geodesy, and GPS, Wellesley - Cambridge Press, 1977.
202
APPENDICES
Appendix A. Open Authentication Service – Summary of User Needs and High Level Requirements Justification ...... 204 Appendix B. NMA Bit-level Field Description ...... 209 Appendix C. Bandwidth Allocation Analysis for Different MAC and Key Sizes ...... 220 Appendix D. Snapshot Authentication ...... 226 Appendix E. Acronyms ...... 237 Appendix F. Published Papers ...... 243
SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Appendix A. Open Authentication Service – Summary of User Needs and High Level Requirements Justification
This appendix presents the justification for the user needs and high level requirements used for the design of the NMA solution presented in Chapter 3. They were defined prior to the definition of any authentication solution. They are divided in these categories:
Target Users and Receiver Constraints Robustness and Performance Feasibility Backward Compatibility
TARGET USERS AND RECEIVER CONSTRAINTS
The authentication solution proposed can be part of the Galileo Open Service. Currently, the biggest Galileo OS user base is foreseen to be portable handset devices (mobile phones, PNDs, tablets or the like) for personal or vehicular use, as is now the case for GPS SPS. This is translated into the following requirements.
The solution shall work in standalone mode: Many OS users will not have a communication channel always available, so the authentication service shall work in standalone mode, as the OS navigation service does.
The solution shall work in assisted mode: Users may have a communication channel (A-GNSS) available for data reception and synchronisation to decrease time to fix and increase sensitivity. The service should therefore take advantage of an A-GNSS communication channel. Ideally, an instantaneous authenticated PVT in assisted mode should be targeted.
Security-related receiver requirements shall be minimised: Symmetric encryption, which implies sharing a secret key between the provider and the user, must be avoided, as the receiver would then need a continuous and authenticated communication channel or a tamper-proof security module. Furthermore, it is then likely that a complicated key
204
management process is put in place to provide and update the secret keys. Therefore, asymmetric methods are proposed. This includes asymmetry obtained through a delayed delivery of a symmetric key, as explained later.
The solution must be E1 mono-frequency: The authentication solution should be based on E1 only, if possible, as opposed to a dual frequency solution, the reason being that most mass-market devices are foreseen to remain E1/L1 single frequency for the following years, due mainly to power consumption reasons. E1 is the band compatible with GPS so it is the obvious choice. The solution may, however, be expandable to other frequencies (note that the I/NAV message is transmitted in both E1 and E5b).
The solution shall not require any additional hardware components than those of a standard low-cost receiver: As mentioned above, no additional hardware has to be required (as e.g. several antennas, INS (Inertial Navigation System), odometers, compass), although the solution must, in the future, be compatible with them. The service must be implementable with low-cost components available in low cost GNSS chips as e.g. crystal oscillators, low-cost antennas and front-end components, and small memories and CPUs that will be integrated into mass-market equipment.
The solution shall be computationally feasible in a standard low-cost receiver: The computational workload for the authentication mechanism shall be affordable and therefore in the order of (or below) the standard receiver processing tasks such as PVT computation. If this requirement is fulfilled, future software-oriented architectures should also be compatible.
ROBUSTNESS AND PERFORMANCE
The solution proposed must be assessed against other state-of-the-art solutions for GNSS authentication. The following requirements summarise some issues to be considered from the point of view of the security robustness of a cryptographic system and include some metrics to be looked at to assess the performance of the solution.
The solution shall use functions and protocols considered secure by the cryptographic community: Attacks to asymmetric key systems rely on mathematical techniques combined with exhaustive key searches. New ideas not tested by the cryptographic community over several years, even if ascertained as secure enough, can be subject to unforeseen mathematical attacks that can render the whole system insecure.
205 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
The solution shall be cryptographically secure in the long term: A period of 30 years since its implementation is considered the lower bound of long-term security as presented in [54]. This is considered as a stringent yet desirable requirement taking into account the evolution pace of GNSS services and infrastructure. Moreover, these figures are also considered in some references [23, 97] from cryptography standardisation and security bodies, as e.g. NIST (National Institute of Standards and Technology) or NSA (National Security Agency), to assess the number of symmetric security bits required for a system to be cryptographically secure in the next years. These projections are based on how technology evolution can make exhaustive key searches or mathematical attacks much shorter than the cryptoperiod in a way that the keys can be broken by an attacker. These projections take into account Moore's law and the use of disruptive technologies as quantum computers that may come in the following years [14].
The satellite and receiver key update frequency must be minimised: If the proposal needs the receiver to handle cryptographic keys, these will not need to be updated with a high frequency. The period during which a key can be utilised must be in the order of around a year, several years or even the whole the lifetime of the system. The system shall also be designed in a way to allow changing the keys quickly if the keys have been compromised.
The proposal robustness to attacks shall be at least comparable to other solutions in the state-of-the-art: They authentication services can be summarised in two categories: Authentication of the navigation data, and protection against replay attacks. For the latter, the unpredictable features of the authentication information can be used. In addition, to increase robustness against replay attacks, the time between authentication events must be minimised.
The proposal performance shall at least be comparable to other authentication proposals in the state-of-the-art: The performance must be assessed for Standalone mode (i.e. the receiver does not have any communication channel to provide assisted information) and assisted mode (i.e. the receiver has a communication channel to provide satellite ephemeris and estimated initial position and time).
206
FEASIBILITY
The implementation of the NMA proposal should be feasible within the boundaries of the Galileo first generation system as foreseen, with minor modifications, if any. This can be translated in the following requirements:
The solution shall be compatible with current Galileo satellites: No modifications to the satellite hardware or software should be envisaged.
The solution shall be compatible with Galileo uplink capabilities: The service proposed should be implementable taking into account that part of the satellites seen by a user at a time will be connected to ground, but the majority will not.
The solution shall be compatible with the Galileo ground segment: The service proposed shall leverage the existing capabilities of the existing ground segment and minimise the modifications to its baseline and associated documentation. The number of ground elements and interfaces modified shall be minimised, and no increase in the system infrastructure, including redundancies, new stations or equipment, or additional network requirements, shall be required.
The solution shall be compatible with the Galileo operations concept: No or minimal changes in operational procedures and effort associated shall be required.
BACKWARD COMPATIBILITY
The elements already defined in the SIS ICD should remain unchanged so that existing Galileo-enabled receivers built according to the OS SIS ICD specification should not be impacted at the time the authentication service is applied.
The solution shall be compatible with the current Galileo signal specification: The authentication service shall not modify the current signal properties as signal power, modulation, pseudorandom codes, secondary codes, or other parameters already defined in the SIS ICD [12].
The solution shall not degrade the Galileo navigation data transmission performance: To keep backward compatibility, the service must be relayed in currently unused data fields. It shall not use the fields currently defined in the SIS ICD. It shall not
207 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION increase the overhead of the navigation data transmission by leading to a higher data aging or TTFF.
The solution shall not prevent other signal evolutions: At the time this text is written, some signal and message evolutions are under consideration. Future services as e.g. support to integrity monitoring, may be occupy the E1 channel. Therefore, the authentication solution shall leave some spare bit capacity unused in a way that does not prevent the implementation of options already under discussion for future implementation.
208
Appendix B. NMA Bit-level Field Description
To improve the readability of the thesis, the details of the bit-level NMA implementation proposal is presented in this appendix.
H-K-ROOT
The following sections describe the H-K-root fields in detail: H-K-root Header, Digital Signature Header, and Digital Signature and Message.
1) H-K-root Header
At the beginning of each subframe, an authentication header is transmitted. It includes the fields Overall NMA status, Chain ID, New K-root flag, End-of-chain flag, DS-ID, Block-ID and reserved bits for future use. If there is no need for the receiver to decode the K-root part, the second half of the header (8 bits in the 2ndsubframe word) could be ignored. Therefore, the two 8-bit parts of the header can be treated separately.
Overall NMA Status (2 bits): These bits present the overall status of the navigation message authentication service as follows:
Table 27 –NMA Overall Status
0 1 2 3 test-1 test-2 operational don't use The modes are described as follows:
"Test-1" mode indicates that authentication is provided without any operational guarantees. In test-1 mode, all connected satellites are transmitting the same information. This mode is defined to cope with a current limitation in the "Reserved 1" bit transmission in the Galileo system. "Test-2" indicates that authentication is provided without any operational guarantees. In test-2 mode, connected satellites are able to transmit different information, as in the operational case. "Operational" mode indicates that the authentication service is providing according to the specifications. "Don't use" mode warns the user not to use the authentication service.
209 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Chain ID (2 bits): ID of the chain in force in the MAC-K section.
New K-root Flag (1 bit): In nominal operations, the K-roots transmitted are the same as in previous subframes, and once a valid K-root of the chain in force is known by the receiver, the receiver does not need to process more K-roots, until it is notified through the end-of-chain flag. Nevertheless, the receiver will be notified when a new K-root (either a more recent one from the current chain or one from the next chain) is transmitted. In this case, this bit is set to '1', to alert the receiver that it can read the new K-root. Otherwise, this bit is set to '0'.
End-Of-Chain Flag (1 bit): When this bit is '1', the users are notified that the current chain ID is coming to an end, so the users should start processing a K-root from another chain ID, as it is expected that the system will start authentication with this new chain.
Reserved (2 bits): Bits of the header reserved for future use. For example, to indicate whether the signature being transmitted is signing a K-root or a new public key, if an over-the-air-rekeying approach is followed. This latter option is not considered in detail in this specification and is left for further work.
Digital Signature ID (4 bits): As a digital signature is transmitted in several blocks (one block per subframe), DS-ID identifies which is the digital signature associated to the current block. In this way, nominal operation could allow the same or different signatures be transmitted from different satellites in an asynchronous way (but keeping synchronicity with the subframe structure).
Digital Signature Block ID (4 bits): This field represents the ID of the current block. The blocks will in general be transmitted sequentially, but the current definition allows for scattered blocks, in case e.g., there is a problem in the EDBS transmission from the system and a block is rebroadcast. It is not foreseen that more than 16 blocks (1920 bits, 1656 bits of DSM) are necessary for the K-root transmission.
Table 28 –Block ID field
Block ID value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Block ID 16 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
210
2) Digital Signature Header
In the first subframe of an H-K-root, the H-K-root incorporates a header that will define some properties about the root key (K-root) and the digital signature used. When BID = 1 (1st block), the receiver will know that a DS Header is coming. The DS Header includes the following fields:
Number of Blocks (4 bits): This field represents the number of blocks of the current signature. Note that the 4-bit value does not express directly the number of blocks and needs to be converted as per Table 29. According to the current definition, the maximum DSM length is 104i – 8, i being the number of blocks. This table also shows DSM lengths for different blocks.
Table 29 – Number of K-root blocks field and maximum DSM length
NB value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Number of 3 4 5 6 7 8 9 10 11 12 rsvd rsvd rsvd rsvd rsvd rsvd blocks DSM length 304 408 512 616 720 824 928 1032 1136 1240 TBD TBD TBD TBD TBD TBD
Now 12 blocks seems enough as they allow signing a 512-bit key with a 512-bit key for OTAR, with some margin. Future versions of the ICD could accommodate longer public keys to increase the key pair validity period or increase security, if vulnerabilities are found.
Public Key ID (4 bits): In order to facilitate the use of keys when the receiver is built, several public keys may be required. Public keys should be published just before their validity period, as otherwise the paired private key could be attacked by the knowledge of the public key, even if no information has been yet signed with it. However, the requirement to connect the receiver to a network to upload new public keys should be minimised. To solve that, the system may define overlaps between in validity periods of several key pairs. For example, if there were no overlap, a receiver manufactured just before the end of the validity period of a certain key Vi, would be forced to be upgraded to load the new public key Vi+1 at the start of its life cycle. To avoid this, public keys can be overlapped, so that at a certain time several keys are valid and the system can transmit digital signatures with different keys.
211 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Table 30 – Public Key Validity Period for several key pairs, assuming each key pair is valid for 5 years
2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 S1, V1 S2, V2 S3, V3 S4, V4 S5, V5 S6, V6 S7, V7 S8, V8 S9,V9
Table 30 shows how several key pairs would be valid for different periods. For example, a receiver manufactured in 2021 could load in its memory the public keys V2, V3, V4, V5 and V6. This would ensure a lifetime of 5 years without the need to upgrade the public keys.
A 4-bit public key ID would allow up to 16 keys in force, which seems more than sufficient, assuming one key is provided every year, and keys are valid for 5 years as in this case. During the lifetime of the system, after the first 16 public keys are used, the public key ID would roll over to zero.
If a private-public key pair has to be revoked, the system will just stop signing H-K-roots with this key, and it will notify through a public internet site or public key infrastructure through an Online Status Certification Protocol (OSCP), that the key is revoked. Even receivers without access to the internet will be able to continue functioning, just by using the other keys.
As mentioned above, another approach for managing public-private key pairs is through over-the-air rekeying (OTAR). In this case, the system would sign a new public key Vi, to be in force in the near future, with the previous public key Si-1, so the receiver can verify its authenticity with Vi-1. If this is implemented, the current DSM scheme could be maintained, but the user flags should be used to notify whether a K-root or a new public key is being transmitted.
3) Digital Signature and Message (DSM)
This section describes the digital signature field. Given that the concept shall allow for different digital signature schemes, some of them allowing message recovery, a single
212
section is considered for the transmission of the digital signature and the message. If the message is not fully recovered from the digital signature, the full message or the part of it that is not recovered is appended just after the digital signature, as shown in Figure 76. If the digital signature plus the message do not sum up to one of these lengths, then the remaining bits can be used to increase redundancy of the data.
Figure 76 – DSM field options The following subsections describe the DSM section, for the case in which a K-root is signed. In this case, the message to be signed is composed of the following fields:
Chain ID (2 bits): ID of the chain to which the K-root belongs. Although in nominal conditions there will only be one valid chain, it seems logical to allow for several chains (up to 4). If a chain is revoked for any reason, the system could start transmitting keys of a new chain in a way that allows the user to determine to which chain a given key belongs and continue authentication in a seamless way.
Key Size (4 bits): It identifies the key size. It represents the size of each key in the chain, including the transmitted K-root. It is interpreted as follows:
Table 31 – Key Size field
Key Size value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Key Size 80 82 84 86 88 90 92 94 96 98 100 112 128 rsvd rsvd rsvd An 80-bit key is considered to be strong enough for long (e.g. 1 year) chain durations, at the time of writing this thesis. Further discussion on key lengths is presented in section 0. The current proposal allows for margin for longer keys to be used in the future. Other key values could be defined. Flexibility in key length also allows bandwidth optimisation, as shown later.
It is assumed that the key size of a certain chain does not change, once the chain has been created and is in use. Therefore, the key size is a parameter that relates to the length of the whole key chain. However, the system can change the key length from one chain to another.
213 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Hash Function (3 bits): It identifies the hash function used for the chain. It is interpreted as follows:
Table 32 – Hash Function field
0 1 2 3 4 5 6 7 8
SHA-256 SHA3-224 SHA3-256 rsvd rsvd rsvd rsvd rsvd rsvd SHA-2 family hashes (SHA-256) are defined in the latest FIPS publication (FIPS PUB 180-4) [55]. SHA-3 family is implemented according to the Keccak algorithm. Draft FIPS PUB 140-2 is under public consultation (as the time of writing this thesis), based on the Keccak algorithm [56]. A new reference standard for SHA-3 shall be given, when available.
This field provides some reserved values for future standard hash functions that may be standardised. Given the high length of the chains, the algorithm implementation is very sensitive to the hash function, a simple, yet secure, function should be used.
MAC Function (2 bits): It identifies the MAC function used with the keys of the chain. It is interpreted as follows:
Table 33 – MAC Function15 - specific implementations
0 1 2 3
HMAC-SHA-256 CMAC-AES rsvd rsvd Option 0: standardized in [98] and in [49].
Option 1: CMAC-AES, standardized as Algorithm 5 in [50], and in [99].
MAC Size (4 bits): This field tells the degree of truncation of the abovementioned MAC, according to the following definition:
Table 34 – MAC Truncation
MAC Trunc. Value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Trunc. MAC length 10 11 12 13 14 15 16 17 18 19 20 rsvd rsvd rsvd rsvd rsvd
15The a and b constants required for the HMAC function can be given in the signal and service specification documents. There is no need to transmit them in the signature. The same occurs for other parameters in other cryptographic functions.
214
In this way, the service can provide more truncated or less truncated MACs, depending of e.g. the number of satellites to be authenticated, out of the existing constellation(s). For example, in test-1 mode, short MACs may be used, as the same data will be sent from all satellites. This flexibility can also accommodate different degrees of uplink capabilities of the system.
WN-K-root (12 bits): this parameter refers to the time associated to the K-root, in Galileo System Time (GST). It provides the Week Number of the time associated to K- root (T-K-root). WN is represented in 12 bits as in the Galileo SIS ICD [12].
DOW-K-root (3 bits): Day of week associated to K-root. The combination of WN-K- root and DOW-K-root should give an unambiguous time reference associated to K-root in the following way: K-root is the key immediately preceding the first key of the chain whose application time corresponds to the subframe starting at WN, DOW at 00:00:00, GST. The K-root is therefore derivable from the first key applicable at this time in just one step.
WN-K-root and DOW-K-root compose the time associated to K-root, or T-K-root. 1 day of resolution is considered enough for T-K-root. More resolution (up to the second level) can be added if entropy needs to be increased to avoid pre-computation attacks.
K-root (80-128 bits): Root key associated to T-K-root. Several K-roots of the same chain associated to different times can be transmitted by the system. Therefore, the term K0 used in previous documentation has been replaced by a 'floating' term K-root, as K0 may be associated to a certain fixed place in the chain, which, if it corresponds to the beginning of the chain, it would require to perform several million hashes to verify the validity of a new key.
Therefore, according to the current proposal, the message to be signed is composed of the following fields with the following lengths:
Table 35 – K-root message
field CID KS HF MF MS WN DOW Kroot total length
length 2 4 3 2 4 12 3 80-128 110-158 If a pattern needs to be added, it would be added as an element of this table.
Digital Signature Generation: two examples of digital signatures types, with and without message recovery, are Nyberg-Rueppel [100] and Schnorr-DSA [101]. They can
215 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION both provide a high level of security with 512-bit signatures, without precluding the use of shorter signatures (e.g. 448 bits). In the case of K-root signature without message recovery, the message bit stream can be generated as follows:
M = (CID || KS || HF || MF || MS || WNKroot || DOWKroot || Kroot) (B.1)
In the case of K-root signature with message recovery, the message to sign requires a certain pattern, to verify the authenticity and integrity of the message:
M = (CID || KS || HF || MF || MS || WNKroot || DOWKroot || Kroot || pattern) (B.2)
MAC-K SECTIONS
Each MAC-K section is composed of the following fields:
1) MAC
Message Authentication Code generated according to equations (3.13) and (3.14).
2) MAC-Info
This field contains the fields SVID, Authentication Data & Key Delay and Issue Of Data, as shown in Table 36.
Table 36 – MAC-Info
field SVID ADKD IOD total length
length 8 4 4 16
SVID (8 bits): Satellite ID of the satellite transmitting navigation data that is authenticated. By using 8 bits, up to 255 satellites could be authenticated, which allows for the authentication of satellite data from Galileo and other constellations (mainly GPS but also, GLONASS, Beidou or others) and regional systems as SBAS. The convention proposed for the SVID field is:
SVID 0: reserved. SVIDs 1-32: Galileo SVIDs as per Galileo signal specification [12].
216
SVIDs 33-64: GPS SVIDs as per GPS signal specification [11], minus 32 (e.g. SVID 33 is GPS SVID 1) SVID 65-96: GLONASS satellite numbers as per GLONASS ICD [102], minus 64. (e.g. SVID 65 is GLONASS SVID 1). SVID 97-128: TBC - Beidou MEO SVIDs as per Beidou ICD [103], minus 96. (e.g. SVID 97 is Beidou SVID 1). SVID 129-160: SBAS GEO SVIDs. Exact allocation TBC (e.g. WAAS MOPS PRN minus 9; e.g. SVID 129 is WAAS MOPS PRN120). 32 values can include GEO satellites from all SBAS: EGNOS, WAAS, MSAS …). SVID 161-255: reserved (e.g. IRNSS). SVID 252: general BEIDOU constellation information that does not relate specifically to a satellite. SVID 253: general GLONASS constellation information that does not relate specifically to a satellite (e.g. ionospheric corrections). SVID 254: general GPS constellation information that does not relate specifically to a satellite (e.g. ionospheric corrections). SVID 255: general Galileo constellation information that does not relate specifically to a satellite (e.g. ionospheric corrections).
Authentication Data and Key Delay (ADKD) (4 bits): This field describes the signed navigation data and, in the case of the "Slow MAC" values, the time between the MAC and the associated key transmission.
The proposed meaning of ADKD bits for Galileo is:
'0', eph&clk: the MAC authenticates the bits of the fields related to the ephemeris, including clock corrections, of the given satellite. It refers to the ephemeris and clock data bits transmitted in the E1 I/NAV message, Words 1 to 4 of [12]. The SISA field will also be included. The spare bits are not included. '1', ionoBGD: the MAC authenticates the bits of the fields related to the ionospheric corrections, BGDs, satellite health and Galileo system time, i.e. all data bits in E1 I/NAV message Word 5: iono correction, BGDs, HS (Health Status), DVS (Data Validity Status) and GST.
217 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
'2', subframe (SF): the MAC authenticates the bits of a certain full subframe. This includes all the Word data. It does not include other reserved fields, the SAR data or the CRC. '3', Gal F/NAV eph&clk: the MAC authenticates the ephemeris and clocks of the F/NAV message. Exact definition is TBC. '11' to '15', "slow MACs": As described in [46], a requirement of the TESLA protocol is a loose time synchronisation between the sender and the receiver. In order to prevent attacks whereby the attacker would rebroadcast a right key with forged navigation and MACs, which could happen if the receiver has a time uncertainty in the order of the seconds between the reception of the MACs and the key, the concept of "slow MACs" is added. A "slow MAC" is a MAC generated with a key broadcast some subframes later. For example, if ADKD field is 12, it means that the receiver gets the key associated to that MAC exactly with two subframes (60 seconds) delay with respect to the time it would have received it in normal conditions. The TTFAF of a receiver requiring the use of 'slow-MAC's to achieve the loose time synchronisation required for TESLA may be degraded by the extra delay between the MACs and the associated key. In a similar implementations, "slow MACs" could refer to the delay measured in "authentication frames" (i.e. MAC-K sections) as opposed to I/NAV subframes.
The proposed meaning of ADKD bits for GPS is:
'0', eph&clk: In case of a GPS satellite, it refers to the bits transmitted in the GPS L1 C/A signal for clock corrections, SV health/accuracy and ephemeris parameters. This data is included in subframes 1, 2 and 3 of a GPS L1 C/A 30- second frame. '1', ionoBGD: the MAC authenticates the bits of subframes 4 and 5 related to the ionospheric model (other bits not TBC). '2', subframe: the MAC authenticates the bits of a whole 30-second GPS frame, including subframes 1 to 5. '4': GPS L1C eph&clk: the MAC authenticates the ephemeris and clock bits from GPS L1C signal. Exact definition is TBC. '11' to '15': same as for Galileo, but related to GPS eph&clk interpretation.
218
The detailed interpretation of the other values, or of the same values for other constellations, is TBD.
Issue-Of-Data (4 bits): Identification of the Issue Of Data of the signed data. 4 bits are considered be enough, as IOD is updated very seldom, even if IOD transmission is disordered by the GNSS ground segment. IOD can be interpreted as follows:
For eph&clk authentication, the 4 bits can be interpreted as follows: o The first bit is '1' when the system is authenticating a new IOD, and '0' otherwise. o The last 3 bits correspond to the IOD truncated to the LSB (Least Significant Bit). o For Galileo satellites and eph&clk authentication, the last 3bits of IOD correspond to the truncated IODnav. o For GPS satellites and eph&clk authentication, the last 3bits of IOD correspond to the truncated IOD Ephemeris. The IOD Clock associated to the authenticated clock corrections is not necessary to be transmitted. It can be assumed by the receiver that the authenticated clock corrections will be those transmitted together with the last authenticated IODE. For Galileo and GPS satellites and ionoBGD (Word 5) authentication, the last 3 bits of IOD are set to zero. The first bit will be '1' when the system is authenticating a new set of ionospheric data. The receiver will assume (TBC) that the data corresponds to the last full subframe (Galileo) or frame (GPS) received. For type '2' – subframe authentication, the first bit is '1' if the subframe authenticated corresponds to the current subframe and '0 if it corresponds to the last subframe16.
3) KEY
This field will contain the key.
16 Note that through E1 and E5b the Datagen can get all words to be authenticated around second 9 of the subframe. This will allow signing the data and having it sent by the end of the same subframe.
219 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Appendix C. Bandwidth Allocation Analysis for Different MAC and Key Sizes
This annex presents the tables used for selecting MAC and key sizes. The tables represent the design parameters for different MAC and key sizes, at a given MAC-K section length. First, the case of 3 MAC-K sections per subframe (one every 10s) is represented. Then, the case with two MAC-K section per subframe (one every 15s in average) is represented.
Each sub-table is formed by 11 rows representing the cases of 10-bit to 20-bit MACs, and each column represents the key size, between 80 bits to 128 bits. The table results are coloured according to their value, to visually indicate the optimal parameters.
The first sub-table (blue) represents the number of MACs that fit into a MAC-K section for a given MAC/K-size pair. The numbers in red represent the cases where the MAC- key combination leaves no spare bits.
The second sub-table (green) represents the total number of MACs transmitted per 30s I/NAV subframe, per channel (i.e. connected satellite).
The third sub-table (red) represents the number of spare bits of the given combination. Only values leaving no spare bits are selected for analysis.
The fourth and fifth sub-tables (red-green) represent the number of unpredictable symbols every 30 seconds, and its percentage, for consideration to protect against replay attacks. Note that the percentage is calculated with respect to the number of authentication bits (20 bps), and not to the total number of I/NAV bits in the I/NAV message structure, in order to better assess the sensitivity of different approaches, which otherwise will be masked by the repeatability of the I/NAV message.
Only the MACs and some of the key bits are considered unpredictable. The input variable 'predictable key bits' is subtracted to the key length to exclude the last bits of the key from the unpredictability test statistics.
220
The sixth sub-table presents the NA (i.e. number of bits for authentication) required to data-authenticate four satellites.
The following input parameters are assumed:
Kpred: 20 TOTAL I/NAV EDBS symbols/30s: 600 Total MAC-K bits available: 480 MAC Info Length: 16
221
Table 37 - Authentication design parameters vs MAC/key lengths - 2 MAC-K sections / SF (i)
1- NB OF MACS PER MAC-K MAC length 2- NB OF MACS PER 30S MAC length 3- MAC-K SPARE BITS MAC length Key length 10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20 80 6 5 5 5 5 5 5 4 4 4 4 12 10 10 10 10 10 10 8 8 8 8 4 25 20 15 10 5 0 28 24 20 16 81 6 5 5 5 5 5 4 4 4 4 4 12 10 10 10 10 10 8 8 8 8 8 3 24 19 14 9 4 31 27 23 19 15 82 6 5 5 5 5 5 4 4 4 4 4 12 10 10 10 10 10 8 8 8 8 8 2 23 18 13 8 3 30 26 22 18 14 83 6 5 5 5 5 5 4 4 4 4 4 12 10 10 10 10 10 8 8 8 8 8 1 22 17 12 7 2 29 25 21 17 13 84 6 5 5 5 5 5 4 4 4 4 4 12 10 10 10 10 10 8 8 8 8 8 0 21 16 11 6 1 28 24 20 16 12 85 5 5 5 5 5 5 4 4 4 4 4 10 10 10 10 10 10 8 8 8 8 8 25 20 15 10 5 0 27 23 19 15 11 86 5 5 5 5 5 4 4 4 4 4 4 10 10 10 10 10 8 8 8 8 8 8 24 19 14 9 4 30 26 22 18 14 10 87 5 5 5 5 5 4 4 4 4 4 4 10 10 10 10 10 8 8 8 8 8 8 23 18 13 8 3 29 25 21 17 13 9 88 5 5 5 5 5 4 4 4 4 4 4 10 10 10 10 10 8 8 8 8 8 8 22 17 12 7 2 28 24 20 16 12 8 89 5 5 5 5 5 4 4 4 4 4 4 10 10 10 10 10 8 8 8 8 8 8 21 16 11 6 1 27 23 19 15 11 7 90 5 5 5 5 5 4 4 4 4 4 4 10 10 10 10 10 8 8 8 8 8 8 20 15 10 5 0 26 22 18 14 10 6 91 5 5 5 5 4 4 4 4 4 4 4 10 10 10 10 8 8 8 8 8 8 8 19 14 9 4 29 25 21 17 13 9 5 92 5 5 5 5 4 4 4 4 4 4 4 10 10 10 10 8 8 8 8 8 8 8 18 13 8 3 28 24 20 16 12 8 4 93 5 5 5 5 4 4 4 4 4 4 4 10 10 10 10 8 8 8 8 8 8 8 17 12 7 2 27 23 19 15 11 7 3 94 5 5 5 5 4 4 4 4 4 4 4 10 10 10 10 8 8 8 8 8 8 8 16 11 6 1 26 22 18 14 10 6 2 95 5 5 5 5 4 4 4 4 4 4 4 10 10 10 10 8 8 8 8 8 8 8 15 10 5 0 25 21 17 13 9 5 1 96 5 5 5 4 4 4 4 4 4 4 4 10 10 10 8 8 8 8 8 8 8 8 14 9 4 28 24 20 16 12 8 4 0 97 5 5 5 4 4 4 4 4 4 4 3 10 10 10 8 8 8 8 8 8 8 6 13 8 3 27 23 19 15 11 7 3 35 98 5 5 5 4 4 4 4 4 4 4 3 10 10 10 8 8 8 8 8 8 8 6 12 7 2 26 22 18 14 10 6 2 34 99 5 5 5 4 4 4 4 4 4 4 3 10 10 10 8 8 8 8 8 8 8 6 11 6 1 25 21 17 13 9 5 1 33 100 5 5 5 4 4 4 4 4 4 4 3 10 10 10 8 8 8 8 8 8 8 6 10 5 0 24 20 16 12 8 4 0 32 101 5 5 4 4 4 4 4 4 4 3 3 10 10 8 8 8 8 8 8 8 6 6 9 4 27 23 19 15 11 7 3 34 31 102 5 5 4 4 4 4 4 4 4 3 3 10 10 8 8 8 8 8 8 8 6 6 8 3 26 22 18 14 10 6 2 33 30 103 5 5 4 4 4 4 4 4 4 3 3 10 10 8 8 8 8 8 8 8 6 6 7 2 25 21 17 13 9 5 1 32 29 104 5 5 4 4 4 4 4 4 4 3 3 10 10 8 8 8 8 8 8 8 6 6 6 1 24 20 16 12 8 4 0 31 28 105 5 5 4 4 4 4 4 4 3 3 3 10 10 8 8 8 8 8 8 6 6 6 5 0 23 19 15 11 7 3 33 30 27 106 5 4 4 4 4 4 4 4 3 3 3 10 8 8 8 8 8 8 8 6 6 6 4 26 22 18 14 10 6 2 32 29 26 107 5 4 4 4 4 4 4 4 3 3 3 10 8 8 8 8 8 8 8 6 6 6 3 25 21 17 13 9 5 1 31 28 25 108 5 4 4 4 4 4 4 4 3 3 3 10 8 8 8 8 8 8 8 6 6 6 2 24 20 16 12 8 4 0 30 27 24 109 5 4 4 4 4 4 4 3 3 3 3 10 8 8 8 8 8 8 6 6 6 6 1 23 19 15 11 7 3 32 29 26 23 110 5 4 4 4 4 4 4 3 3 3 3 10 8 8 8 8 8 8 6 6 6 6 0 22 18 14 10 6 2 31 28 25 22 111 4 4 4 4 4 4 4 3 3 3 3 8 8 8 8 8 8 8 6 6 6 6 25 21 17 13 9 5 1 30 27 24 21 112 4 4 4 4 4 4 4 3 3 3 3 8 8 8 8 8 8 8 6 6 6 6 24 20 16 12 8 4 0 29 26 23 20 113 4 4 4 4 4 4 3 3 3 3 3 8 8 8 8 8 8 6 6 6 6 6 23 19 15 11 7 3 31 28 25 22 19 114 4 4 4 4 4 4 3 3 3 3 3 8 8 8 8 8 8 6 6 6 6 6 22 18 14 10 6 2 30 27 24 21 18 115 4 4 4 4 4 4 3 3 3 3 3 8 8 8 8 8 8 6 6 6 6 6 21 17 13 9 5 1 29 26 23 20 17 116 4 4 4 4 4 4 3 3 3 3 3 8 8 8 8 8 8 6 6 6 6 6 20 16 12 8 4 0 28 25 22 19 16 117 4 4 4 4 4 3 3 3 3 3 3 8 8 8 8 8 6 6 6 6 6 6 19 15 11 7 3 30 27 24 21 18 15 118 4 4 4 4 4 3 3 3 3 3 3 8 8 8 8 8 6 6 6 6 6 6 18 14 10 6 2 29 26 23 20 17 14 119 4 4 4 4 4 3 3 3 3 3 3 8 8 8 8 8 6 6 6 6 6 6 17 13 9 5 1 28 25 22 19 16 13 120 4 4 4 4 4 3 3 3 3 3 3 8 8 8 8 8 6 6 6 6 6 6 16 12 8 4 0 27 24 21 18 15 12 121 4 4 4 4 3 3 3 3 3 3 3 8 8 8 8 6 6 6 6 6 6 6 15 11 7 3 29 26 23 20 17 14 11 122 4 4 4 4 3 3 3 3 3 3 3 8 8 8 8 6 6 6 6 6 6 6 14 10 6 2 28 25 22 19 16 13 10 123 4 4 4 4 3 3 3 3 3 3 3 8 8 8 8 6 6 6 6 6 6 6 13 9 5 1 27 24 21 18 15 12 9 124 4 4 4 4 3 3 3 3 3 3 3 8 8 8 8 6 6 6 6 6 6 6 12 8 4 0 26 23 20 17 14 11 8 125 4 4 4 3 3 3 3 3 3 3 3 8 8 8 6 6 6 6 6 6 6 6 11 7 3 28 25 22 19 16 13 10 7 126 4 4 4 3 3 3 3 3 3 3 3 8 8 8 6 6 6 6 6 6 6 6 10 6 2 27 24 21 18 15 12 9 6 127 4 4 4 3 3 3 3 3 3 3 3 8 8 8 6 6 6 6 6 6 6 6 9 5 1 26 23 20 17 14 11 8 5 128 4 4 4 3 3 3 3 3 3 3 3 8 8 8 6 6 6 6 6 6 6 6 8 4 0 25 22 19 16 13 10 7 4
Table 38 - Authentication design parameters vs MAC/key lengths - 2 MAC-K sections / SF (ii)
4- UNPRED. SYMBOLS PER 30s MAC length 5- UNPRED. SYMBOL RATIO (VS. EDBS) MAC length 6- NA - 4SV MAC length
10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20 240 230 240 250 260 270 280 256 264 272 280 20.0% 19.2% 20.0% 20.8% 21.7% 22.5% 23.3% 21.3% 22.0% 22.7% 23.3% 184 188 192 196 200 204 208 212 216 220 224 242 232 242 252 262 272 250 258 266 274 282 20.2% 19.3% 20.2% 21.0% 21.8% 22.7% 20.8% 21.5% 22.2% 22.8% 23.5% 185 189 193 197 201 205 209 213 217 221 225 244 234 244 254 264 274 252 260 268 276 284 20.3% 19.5% 20.3% 21.2% 22.0% 22.8% 21.0% 21.7% 22.3% 23.0% 23.7% 186 190 194 198 202 206 210 214 218 222 226 246 236 246 256 266 276 254 262 270 278 286 20.5% 19.7% 20.5% 21.3% 22.2% 23.0% 21.2% 21.8% 22.5% 23.2% 23.8% 187 191 195 199 203 207 211 215 219 223 227 248 238 248 258 268 278 256 264 272 280 288 20.7% 19.8% 20.7% 21.5% 22.3% 23.2% 21.3% 22.0% 22.7% 23.3% 24.0% 188 192 196 200 204 208 212 216 220 224 228 230 240 250 260 270 280 258 266 274 282 290 19.2% 20.0% 20.8% 21.7% 22.5% 23.3% 21.5% 22.2% 22.8% 23.5% 24.2% 189 193 197 201 205 209 213 217 221 225 229 232 242 252 262 272 252 260 268 276 284 292 19.3% 20.2% 21.0% 21.8% 22.7% 21.0% 21.7% 22.3% 23.0% 23.7% 24.3% 190 194 198 202 206 210 214 218 222 226 230 234 244 254 264 274 254 262 270 278 286 294 19.5% 20.3% 21.2% 22.0% 22.8% 21.2% 21.8% 22.5% 23.2% 23.8% 24.5% 191 195 199 203 207 211 215 219 223 227 231 236 246 256 266 276 256 264 272 280 288 296 19.7% 20.5% 21.3% 22.2% 23.0% 21.3% 22.0% 22.7% 23.3% 24.0% 24.7% 192 196 200 204 208 212 216 220 224 228 232 238 248 258 268 278 258 266 274 282 290 298 19.8% 20.7% 21.5% 22.3% 23.2% 21.5% 22.2% 22.8% 23.5% 24.2% 24.8% 193 197 201 205 209 213 217 221 225 229 233 240 250 260 270 280 260 268 276 284 292 300 20.0% 20.8% 21.7% 22.5% 23.3% 21.7% 22.3% 23.0% 23.7% 24.3% 25.0% 194 198 202 206 210 214 218 222 226 230 234 242 252 262 272 254 262 270 278 286 294 302 20.2% 21.0% 21.8% 22.7% 21.2% 21.8% 22.5% 23.2% 23.8% 24.5% 25.2% 195 199 203 207 211 215 219 223 227 231 235 244 254 264 274 256 264 272 280 288 296 304 20.3% 21.2% 22.0% 22.8% 21.3% 22.0% 22.7% 23.3% 24.0% 24.7% 25.3% 196 200 204 208 212 216 220 224 228 232 236 246 256 266 276 258 266 274 282 290 298 306 20.5% 21.3% 22.2% 23.0% 21.5% 22.2% 22.8% 23.5% 24.2% 24.8% 25.5% 197 201 205 209 213 217 221 225 229 233 237 248 258 268 278 260 268 276 284 292 300 308 20.7% 21.5% 22.3% 23.2% 21.7% 22.3% 23.0% 23.7% 24.3% 25.0% 25.7% 198 202 206 210 214 218 222 226 230 234 238 250 260 270 280 262 270 278 286 294 302 310 20.8% 21.7% 22.5% 23.3% 21.8% 22.5% 23.2% 23.8% 24.5% 25.2% 25.8% 199 203 207 211 215 219 223 227 231 235 239 252 262 272 256 264 272 280 288 296 304 312 21.0% 21.8% 22.7% 21.3% 22.0% 22.7% 23.3% 24.0% 24.7% 25.3% 26.0% 200 204 208 212 216 220 224 228 232 236 240 254 264 274 258 266 274 282 290 298 306 274 21.2% 22.0% 22.8% 21.5% 22.2% 22.8% 23.5% 24.2% 24.8% 25.5% 22.8% 201 205 209 213 217 221 225 229 233 237 241 256 266 276 260 268 276 284 292 300 308 276 21.3% 22.2% 23.0% 21.7% 22.3% 23.0% 23.7% 24.3% 25.0% 25.7% 23.0% 202 206 210 214 218 222 226 230 234 238 242 258 268 278 262 270 278 286 294 302 310 278 21.5% 22.3% 23.2% 21.8% 22.5% 23.2% 23.8% 24.5% 25.2% 25.8% 23.2% 203 207 211 215 219 223 227 231 235 239 243 260 270 280 264 272 280 288 296 304 312 280 21.7% 22.5% 23.3% 22.0% 22.7% 23.3% 24.0% 24.7% 25.3% 26.0% 23.3% 204 208 212 216 220 224 228 232 236 240 244 262 272 258 266 274 282 290 298 306 276 282 21.8% 22.7% 21.5% 22.2% 22.8% 23.5% 24.2% 24.8% 25.5% 23.0% 23.5% 205 209 213 217 221 225 229 233 237 241 245 264 274 260 268 276 284 292 300 308 278 284 22.0% 22.8% 21.7% 22.3% 23.0% 23.7% 24.3% 25.0% 25.7% 23.2% 23.7% 206 210 214 218 222 226 230 234 238 242 246 266 276 262 270 278 286 294 302 310 280 286 22.2% 23.0% 21.8% 22.5% 23.2% 23.8% 24.5% 25.2% 25.8% 23.3% 23.8% 207 211 215 219 223 227 231 235 239 243 247 268 278 264 272 280 288 296 304 312 282 288 22.3% 23.2% 22.0% 22.7% 23.3% 24.0% 24.7% 25.3% 26.0% 23.5% 24.0% 208 212 216 220 224 228 232 236 240 244 248 270 280 266 274 282 290 298 306 278 284 290 22.5% 23.3% 22.2% 22.8% 23.5% 24.2% 24.8% 25.5% 23.2% 23.7% 24.2% 209 213 217 221 225 229 233 237 241 245 249 272 260 268 276 284 292 300 308 280 286 292 22.7% 21.7% 22.3% 23.0% 23.7% 24.3% 25.0% 25.7% 23.3% 23.8% 24.3% 210 214 218 222 226 230 234 238 242 246 250 274 262 270 278 286 294 302 310 282 288 294 22.8% 21.8% 22.5% 23.2% 23.8% 24.5% 25.2% 25.8% 23.5% 24.0% 24.5% 211 215 219 223 227 231 235 239 243 247 251 276 264 272 280 288 296 304 312 284 290 296 23.0% 22.0% 22.7% 23.3% 24.0% 24.7% 25.3% 26.0% 23.7% 24.2% 24.7% 212 216 220 224 228 232 236 240 244 248 252 278 266 274 282 290 298 306 280 286 292 298 23.2% 22.2% 22.8% 23.5% 24.2% 24.8% 25.5% 23.3% 23.8% 24.3% 24.8% 213 217 221 225 229 233 237 241 245 249 253 280 268 276 284 292 300 308 282 288 294 300 23.3% 22.3% 23.0% 23.7% 24.3% 25.0% 25.7% 23.5% 24.0% 24.5% 25.0% 214 218 222 226 230 234 238 242 246 250 254 262 270 278 286 294 302 310 284 290 296 302 21.8% 22.5% 23.2% 23.8% 24.5% 25.2% 25.8% 23.7% 24.2% 24.7% 25.2% 215 219 223 227 231 235 239 243 247 251 255 264 272 280 288 296 304 312 286 292 298 304 22.0% 22.7% 23.3% 24.0% 24.7% 25.3% 26.0% 23.8% 24.3% 24.8% 25.3% 216 220 224 228 232 236 240 244 248 252 256 266 274 282 290 298 306 282 288 294 300 306 22.2% 22.8% 23.5% 24.2% 24.8% 25.5% 23.5% 24.0% 24.5% 25.0% 25.5% 217 221 225 229 233 237 241 245 249 253 257 268 276 284 292 300 308 284 290 296 302 308 22.3% 23.0% 23.7% 24.3% 25.0% 25.7% 23.7% 24.2% 24.7% 25.2% 25.7% 218 222 226 230 234 238 242 246 250 254 258 270 278 286 294 302 310 286 292 298 304 310 22.5% 23.2% 23.8% 24.5% 25.2% 25.8% 23.8% 24.3% 24.8% 25.3% 25.8% 219 223 227 231 235 239 243 247 251 255 259 272 280 288 296 304 312 288 294 300 306 312 22.7% 23.3% 24.0% 24.7% 25.3% 26.0% 24.0% 24.5% 25.0% 25.5% 26.0% 220 224 228 232 236 240 244 248 252 256 260 274 282 290 298 306 284 290 296 302 308 314 22.8% 23.5% 24.2% 24.8% 25.5% 23.7% 24.2% 24.7% 25.2% 25.7% 26.2% 221 225 229 233 237 241 245 249 253 257 261 276 284 292 300 308 286 292 298 304 310 316 23.0% 23.7% 24.3% 25.0% 25.7% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 222 226 230 234 238 242 246 250 254 258 262 278 286 294 302 310 288 294 300 306 312 318 23.2% 23.8% 24.5% 25.2% 25.8% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 223 227 231 235 239 243 247 251 255 259 263 280 288 296 304 312 290 296 302 308 314 320 23.3% 24.0% 24.7% 25.3% 26.0% 24.2% 24.7% 25.2% 25.7% 26.2% 26.7% 224 228 232 236 240 244 248 252 256 260 264 282 290 298 306 286 292 298 304 310 316 322 23.5% 24.2% 24.8% 25.5% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 225 229 233 237 241 245 249 253 257 261 265 284 292 300 308 288 294 300 306 312 318 324 23.7% 24.3% 25.0% 25.7% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 226 230 234 238 242 246 250 254 258 262 266 286 294 302 310 290 296 302 308 314 320 326 23.8% 24.5% 25.2% 25.8% 24.2% 24.7% 25.2% 25.7% 26.2% 26.7% 27.2% 227 231 235 239 243 247 251 255 259 263 267 288 296 304 312 292 298 304 310 316 322 328 24.0% 24.7% 25.3% 26.0% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 27.3% 228 232 236 240 244 248 252 256 260 264 268 290 298 306 288 294 300 306 312 318 324 330 24.2% 24.8% 25.5% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 27.5% 229 233 237 241 245 249 253 257 261 265 269 292 300 308 290 296 302 308 314 320 326 332 24.3% 25.0% 25.7% 24.2% 24.7% 25.2% 25.7% 26.2% 26.7% 27.2% 27.7% 230 234 238 242 246 250 254 258 262 266 270 294 302 310 292 298 304 310 316 322 328 334 24.5% 25.2% 25.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 27.3% 27.8% 231 235 239 243 247 251 255 259 263 267 271 296 304 312 294 300 306 312 318 324 330 336 24.7% 25.3% 26.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 27.5% 28.0% 232 236 240 244 248 252 256 260 264 268 272
223 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Table 39 - Authentication design parameters vs MAC/key lengths - 3 MAC-K sections / SF (i)
1- NB OF MACS PER MAC-K MAC length 2- NB OF MACS PER 30S MAC length 3- MAC-K SPARE BITS MAC length Key length 10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20 80 3 2 2 2 2 2 2 2 2 2 2 9 6 6 6 6 6 6 6 6 6 6 2 26 24 22 20 18 16 14 12 10 8 81 3 2 2 2 2 2 2 2 2 2 2 9 6 6 6 6 6 6 6 6 6 6 1 25 23 21 19 17 15 13 11 9 7 82 3 2 2 2 2 2 2 2 2 2 2 9 6 6 6 6 6 6 6 6 6 6 0 24 22 20 18 16 14 12 10 8 6 83 2 2 2 2 2 2 2 2 2 2 2 6 6 6 6 6 6 6 6 6 6 6 25 23 21 19 17 15 13 11 9 7 5 84 2 2 2 2 2 2 2 2 2 2 2 6 6 6 6 6 6 6 6 6 6 6 24 22 20 18 16 14 12 10 8 6 4 85 2 2 2 2 2 2 2 2 2 2 2 6 6 6 6 6 6 6 6 6 6 6 23 21 19 17 15 13 11 9 7 5 3 86 2 2 2 2 2 2 2 2 2 2 2 6 6 6 6 6 6 6 6 6 6 6 22 20 18 16 14 12 10 8 6 4 2 87 2 2 2 2 2 2 2 2 2 2 2 6 6 6 6 6 6 6 6 6 6 6 21 19 17 15 13 11 9 7 5 3 1 88 2 2 2 2 2 2 2 2 2 2 2 6 6 6 6 6 6 6 6 6 6 6 20 18 16 14 12 10 8 6 4 2 0 89 2 2 2 2 2 2 2 2 2 2 1 6 6 6 6 6 6 6 6 6 6 3 19 17 15 13 11 9 7 5 3 1 35 90 2 2 2 2 2 2 2 2 2 2 1 6 6 6 6 6 6 6 6 6 6 3 18 16 14 12 10 8 6 4 2 0 34 91 2 2 2 2 2 2 2 2 2 1 1 6 6 6 6 6 6 6 6 6 3 3 17 15 13 11 9 7 5 3 1 34 33 92 2 2 2 2 2 2 2 2 2 1 1 6 6 6 6 6 6 6 6 6 3 3 16 14 12 10 8 6 4 2 0 33 32 93 2 2 2 2 2 2 2 2 1 1 1 6 6 6 6 6 6 6 6 3 3 3 15 13 11 9 7 5 3 1 33 32 31 94 2 2 2 2 2 2 2 2 1 1 1 6 6 6 6 6 6 6 6 3 3 3 14 12 10 8 6 4 2 0 32 31 30 95 2 2 2 2 2 2 2 1 1 1 1 6 6 6 6 6 6 6 3 3 3 3 13 11 9 7 5 3 1 32 31 30 29 96 2 2 2 2 2 2 2 1 1 1 1 6 6 6 6 6 6 6 3 3 3 3 12 10 8 6 4 2 0 31 30 29 28 97 2 2 2 2 2 2 1 1 1 1 1 6 6 6 6 6 6 3 3 3 3 3 11 9 7 5 3 1 31 30 29 28 27 98 2 2 2 2 2 2 1 1 1 1 1 6 6 6 6 6 6 3 3 3 3 3 10 8 6 4 2 0 30 29 28 27 26 99 2 2 2 2 2 1 1 1 1 1 1 6 6 6 6 6 3 3 3 3 3 3 9 7 5 3 1 30 29 28 27 26 25 100 2 2 2 2 2 1 1 1 1 1 1 6 6 6 6 6 3 3 3 3 3 3 8 6 4 2 0 29 28 27 26 25 24 101 2 2 2 2 1 1 1 1 1 1 1 6 6 6 6 3 3 3 3 3 3 3 7 5 3 1 29 28 27 26 25 24 23 102 2 2 2 2 1 1 1 1 1 1 1 6 6 6 6 3 3 3 3 3 3 3 6 4 2 0 28 27 26 25 24 23 22 103 2 2 2 1 1 1 1 1 1 1 1 6 6 6 3 3 3 3 3 3 3 3 5 3 1 28 27 26 25 24 23 22 21 104 2 2 2 1 1 1 1 1 1 1 1 6 6 6 3 3 3 3 3 3 3 3 4 2 0 27 26 25 24 23 22 21 20 105 2 2 1 1 1 1 1 1 1 1 1 6 6 3 3 3 3 3 3 3 3 3 3 1 27 26 25 24 23 22 21 20 19 106 2 2 1 1 1 1 1 1 1 1 1 6 6 3 3 3 3 3 3 3 3 3 2 0 26 25 24 23 22 21 20 19 18 107 2 1 1 1 1 1 1 1 1 1 1 6 3 3 3 3 3 3 3 3 3 3 1 26 25 24 23 22 21 20 19 18 17 108 2 1 1 1 1 1 1 1 1 1 1 6 3 3 3 3 3 3 3 3 3 3 0 25 24 23 22 21 20 19 18 17 16 109 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 25 24 23 22 21 20 19 18 17 16 15 110 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 24 23 22 21 20 19 18 17 16 15 14 111 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 23 22 21 20 19 18 17 16 15 14 13 112 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 22 21 20 19 18 17 16 15 14 13 12 113 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 21 20 19 18 17 16 15 14 13 12 11 114 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 20 19 18 17 16 15 14 13 12 11 10 115 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 19 18 17 16 15 14 13 12 11 10 9 116 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 18 17 16 15 14 13 12 11 10 9 8 117 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 17 16 15 14 13 12 11 10 9 8 7 118 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 16 15 14 13 12 11 10 9 8 7 6 119 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 15 14 13 12 11 10 9 8 7 6 5 120 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 14 13 12 11 10 9 8 7 6 5 4 121 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 13 12 11 10 9 8 7 6 5 4 3 122 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 12 11 10 9 8 7 6 5 4 3 2 123 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 11 10 9 8 7 6 5 4 3 2 1 124 1 1 1 1 1 1 1 1 1 1 1 3 3 3 3 3 3 3 3 3 3 3 10 9 8 7 6 5 4 3 2 1 0 125 1 1 1 1 1 1 1 1 1 1 0 3 3 3 3 3 3 3 3 3 3 0 9 8 7 6 5 4 3 2 1 0 35 126 1 1 1 1 1 1 1 1 1 0 0 3 3 3 3 3 3 3 3 3 0 0 8 7 6 5 4 3 2 1 0 34 34 127 1 1 1 1 1 1 1 1 0 0 0 3 3 3 3 3 3 3 3 0 0 0 7 6 5 4 3 2 1 0 33 33 33 128 1 1 1 1 1 1 1 0 0 0 0 3 3 3 3 3 3 3 0 0 0 0 6 5 4 3 2 1 0 32 32 32 32
224
Table 40 - authentication design parameters vs MAC/key lengths - 3 MAC-K sections / SF (ii)
4- UNPRED. SYMBOLS PER 30s MAC length 5- UNPRED. SYMBOL RATIO (VS. EDBS) MAC length 6- NA - 4SV MAC length
10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20 10 11 12 13 14 15 16 17 18 19 20 270 246 252 258 264 270 276 282 288 294 300 22.5% 20.5% 21.0% 21.5% 22.0% 22.5% 23.0% 23.5% 24.0% 24.5% 25.0% 184 188 192 196 200 204 208 212 216 220 224 273 249 255 261 267 273 279 285 291 297 303 22.8% 20.8% 21.3% 21.8% 22.3% 22.8% 23.3% 23.8% 24.3% 24.8% 25.3% 185 189 193 197 201 205 209 213 217 221 225 276 252 258 264 270 276 282 288 294 300 306 23.0% 21.0% 21.5% 22.0% 22.5% 23.0% 23.5% 24.0% 24.5% 25.0% 25.5% 186 190 194 198 202 206 210 214 218 222 226 249 255 261 267 273 279 285 291 297 303 309 20.8% 21.3% 21.8% 22.3% 22.8% 23.3% 23.8% 24.3% 24.8% 25.3% 25.8% 187 191 195 199 203 207 211 215 219 223 227 252 258 264 270 276 282 288 294 300 306 312 21.0% 21.5% 22.0% 22.5% 23.0% 23.5% 24.0% 24.5% 25.0% 25.5% 26.0% 188 192 196 200 204 208 212 216 220 224 228 255 261 267 273 279 285 291 297 303 309 315 21.3% 21.8% 22.3% 22.8% 23.3% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 189 193 197 201 205 209 213 217 221 225 229 258 264 270 276 282 288 294 300 306 312 318 21.5% 22.0% 22.5% 23.0% 23.5% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 190 194 198 202 206 210 214 218 222 226 230 261 267 273 279 285 291 297 303 309 315 321 21.8% 22.3% 22.8% 23.3% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 191 195 199 203 207 211 215 219 223 227 231 264 270 276 282 288 294 300 306 312 318 324 22.0% 22.5% 23.0% 23.5% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 192 196 200 204 208 212 216 220 224 228 232 267 273 279 285 291 297 303 309 315 321 267 22.3% 22.8% 23.3% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 22.3% 193 197 201 205 209 213 217 221 225 229 233 270 276 282 288 294 300 306 312 318 324 270 22.5% 23.0% 23.5% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 22.5% 194 198 202 206 210 214 218 222 226 230 234 273 279 285 291 297 303 309 315 321 270 273 22.8% 23.3% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 22.5% 22.8% 195 199 203 207 211 215 219 223 227 231 235 276 282 288 294 300 306 312 318 324 273 276 23.0% 23.5% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 22.8% 23.0% 196 200 204 208 212 216 220 224 228 232 236 279 285 291 297 303 309 315 321 273 276 279 23.3% 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 22.8% 23.0% 23.3% 197 201 205 209 213 217 221 225 229 233 237 282 288 294 300 306 312 318 324 276 279 282 23.5% 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 23.0% 23.3% 23.5% 198 202 206 210 214 218 222 226 230 234 238 285 291 297 303 309 315 321 276 279 282 285 23.8% 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 23.0% 23.3% 23.5% 23.8% 199 203 207 211 215 219 223 227 231 235 239 288 294 300 306 312 318 324 279 282 285 288 24.0% 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 23.3% 23.5% 23.8% 24.0% 200 204 208 212 216 220 224 228 232 236 240 291 297 303 309 315 321 279 282 285 288 291 24.3% 24.8% 25.3% 25.8% 26.3% 26.8% 23.3% 23.5% 23.8% 24.0% 24.3% 201 205 209 213 217 221 225 229 233 237 241 294 300 306 312 318 324 282 285 288 291 294 24.5% 25.0% 25.5% 26.0% 26.5% 27.0% 23.5% 23.8% 24.0% 24.3% 24.5% 202 206 210 214 218 222 226 230 234 238 242 297 303 309 315 321 282 285 288 291 294 297 24.8% 25.3% 25.8% 26.3% 26.8% 23.5% 23.8% 24.0% 24.3% 24.5% 24.8% 203 207 211 215 219 223 227 231 235 239 243 300 306 312 318 324 285 288 291 294 297 300 25.0% 25.5% 26.0% 26.5% 27.0% 23.8% 24.0% 24.3% 24.5% 24.8% 25.0% 204 208 212 216 220 224 228 232 236 240 244 303 309 315 321 285 288 291 294 297 300 303 25.3% 25.8% 26.3% 26.8% 23.8% 24.0% 24.3% 24.5% 24.8% 25.0% 25.3% 205 209 213 217 221 225 229 233 237 241 245 306 312 318 324 288 291 294 297 300 303 306 25.5% 26.0% 26.5% 27.0% 24.0% 24.3% 24.5% 24.8% 25.0% 25.3% 25.5% 206 210 214 218 222 226 230 234 238 242 246 309 315 321 288 291 294 297 300 303 306 309 25.8% 26.3% 26.8% 24.0% 24.3% 24.5% 24.8% 25.0% 25.3% 25.5% 25.8% 207 211 215 219 223 227 231 235 239 243 247 312 318 324 291 294 297 300 303 306 309 312 26.0% 26.5% 27.0% 24.3% 24.5% 24.8% 25.0% 25.3% 25.5% 25.8% 26.0% 208 212 216 220 224 228 232 236 240 244 248 315 321 291 294 297 300 303 306 309 312 315 26.3% 26.8% 24.3% 24.5% 24.8% 25.0% 25.3% 25.5% 25.8% 26.0% 26.3% 209 213 217 221 225 229 233 237 241 245 249 318 324 294 297 300 303 306 309 312 315 318 26.5% 27.0% 24.5% 24.8% 25.0% 25.3% 25.5% 25.8% 26.0% 26.3% 26.5% 210 214 218 222 226 230 234 238 242 246 250 321 294 297 300 303 306 309 312 315 318 321 26.8% 24.5% 24.8% 25.0% 25.3% 25.5% 25.8% 26.0% 26.3% 26.5% 26.8% 211 215 219 223 227 231 235 239 243 247 251 324 297 300 303 306 309 312 315 318 321 324 27.0% 24.8% 25.0% 25.3% 25.5% 25.8% 26.0% 26.3% 26.5% 26.8% 27.0% 212 216 220 224 228 232 236 240 244 248 252 297 300 303 306 309 312 315 318 321 324 327 24.8% 25.0% 25.3% 25.5% 25.8% 26.0% 26.3% 26.5% 26.8% 27.0% 27.3% 213 217 221 225 229 233 237 241 245 249 253 300 303 306 309 312 315 318 321 324 327 330 25.0% 25.3% 25.5% 25.8% 26.0% 26.3% 26.5% 26.8% 27.0% 27.3% 27.5% 214 218 222 226 230 234 238 242 246 250 254 303 306 309 312 315 318 321 324 327 330 333 25.3% 25.5% 25.8% 26.0% 26.3% 26.5% 26.8% 27.0% 27.3% 27.5% 27.8% 215 219 223 227 231 235 239 243 247 251 255 306 309 312 315 318 321 324 327 330 333 336 25.5% 25.8% 26.0% 26.3% 26.5% 26.8% 27.0% 27.3% 27.5% 27.8% 28.0% 216 220 224 228 232 236 240 244 248 252 256 309 312 315 318 321 324 327 330 333 336 339 25.8% 26.0% 26.3% 26.5% 26.8% 27.0% 27.3% 27.5% 27.8% 28.0% 28.3% 217 221 225 229 233 237 241 245 249 253 257 312 315 318 321 324 327 330 333 336 339 342 26.0% 26.3% 26.5% 26.8% 27.0% 27.3% 27.5% 27.8% 28.0% 28.3% 28.5% 218 222 226 230 234 238 242 246 250 254 258 315 318 321 324 327 330 333 336 339 342 345 26.3% 26.5% 26.8% 27.0% 27.3% 27.5% 27.8% 28.0% 28.3% 28.5% 28.8% 219 223 227 231 235 239 243 247 251 255 259 318 321 324 327 330 333 336 339 342 345 348 26.5% 26.8% 27.0% 27.3% 27.5% 27.8% 28.0% 28.3% 28.5% 28.8% 29.0% 220 224 228 232 236 240 244 248 252 256 260 321 324 327 330 333 336 339 342 345 348 351 26.8% 27.0% 27.3% 27.5% 27.8% 28.0% 28.3% 28.5% 28.8% 29.0% 29.3% 221 225 229 233 237 241 245 249 253 257 261 324 327 330 333 336 339 342 345 348 351 354 27.0% 27.3% 27.5% 27.8% 28.0% 28.3% 28.5% 28.8% 29.0% 29.3% 29.5% 222 226 230 234 238 242 246 250 254 258 262 327 330 333 336 339 342 345 348 351 354 357 27.3% 27.5% 27.8% 28.0% 28.3% 28.5% 28.8% 29.0% 29.3% 29.5% 29.8% 223 227 231 235 239 243 247 251 255 259 263 330 333 336 339 342 345 348 351 354 357 360 27.5% 27.8% 28.0% 28.3% 28.5% 28.8% 29.0% 29.3% 29.5% 29.8% 30.0% 224 228 232 236 240 244 248 252 256 260 264 333 336 339 342 345 348 351 354 357 360 363 27.8% 28.0% 28.3% 28.5% 28.8% 29.0% 29.3% 29.5% 29.8% 30.0% 30.3% 225 229 233 237 241 245 249 253 257 261 265 336 339 342 345 348 351 354 357 360 363 366 28.0% 28.3% 28.5% 28.8% 29.0% 29.3% 29.5% 29.8% 30.0% 30.3% 30.5% 226 230 234 238 242 246 250 254 258 262 266 339 342 345 348 351 354 357 360 363 366 369 28.3% 28.5% 28.8% 29.0% 29.3% 29.5% 29.8% 30.0% 30.3% 30.5% 30.8% 227 231 235 239 243 247 251 255 259 263 267 342 345 348 351 354 357 360 363 366 369 372 28.5% 28.8% 29.0% 29.3% 29.5% 29.8% 30.0% 30.3% 30.5% 30.8% 31.0% 228 232 236 240 244 248 252 256 260 264 268 345 348 351 354 357 360 363 366 369 372 315 28.8% 29.0% 29.3% 29.5% 29.8% 30.0% 30.3% 30.5% 30.8% 31.0% 26.3% 229 233 237 241 245 249 253 257 261 265 269 348 351 354 357 360 363 366 369 372 318 318 29.0% 29.3% 29.5% 29.8% 30.0% 30.3% 30.5% 30.8% 31.0% 26.5% 26.5% 230 234 238 242 246 250 254 258 262 266 270 351 354 357 360 363 366 369 372 321 321 321 29.3% 29.5% 29.8% 30.0% 30.3% 30.5% 30.8% 31.0% 26.8% 26.8% 26.8% 231 235 239 243 247 251 255 259 263 267 271 354 357 360 363 366 369 372 324 324 324 324 29.5% 29.8% 30.0% 30.3% 30.5% 30.8% 31.0% 27.0% 27.0% 27.0% 27.0% 232 236 240 244 248 252 256 260 264 268 272
225
Appendix D. Snapshot Authentication
MOTIVATION
GNSS positioning authentication requires authentic data and time of arrival measurements. While data can be easily authenticated, reception time can be subject to replay attacks, no matter that the signals are protected at spreading code level or at data level, if the spoofer has the adequate means [36].
A receiver that is just switched on can be subject to replay attacks without noticing if it starts acquiring the spoofed signals. The same occurs with snapshot positioning. However, unpredictability poses a constraint to the attacker: If the signals are partly unpredictable and these unpredictable features are later verified, a spoofer could apply a delay to the signal, but it could hardly make the signal arrive earlier. Even if an attacker placed a receiver just below the satellite, and relayed the signal to the spoofer through other means, the signal cannot travel faster than the light speed, so it cannot arrive earlier than from the satellite. Other attacks may look at the early samples after unpredictable symbol transitions, in case of NMA, and make the symbols end faster, modifying the number of codes that compose the pseudorange, but as mentioned in Chapter 3, these attacks can be detected by careful signal processing.
The receiver can however use a trusted reference to time-tag the reception time of the measurements. Still, if a spoofer adds selective delays, depending on the satellite geometry it could induce to coherently false positions, as shown in Figure 77. However, if an approximate height is known and introduced as a constraint, for example from a digital elevation model (DEM), this threat is partly mitigated. This section presents an algebraic description of signal authentication based on a trusted clock reference and the expected user height as an additional constraint. The method can be applied to snapshot positioning, as long as the signals in the snapshot contain features that are unpredictable and verifiable. A similar idea to the one at the core of this chapter has been independently outlined in [28], although the focus of this reference is on other authentication topics and therefore it does not analyse the subject in detail.
BACKGROUND
The principal technical problem of location authentication seems related not to the data authentication, which can be digitally signed, but to ensuring that the measurements used in the position solution are the original ones and not a rebroadcast of them. While signal replay can be detected when an attacker intends to take control of a receiver already tracking authentic signals, at the moment of receiver start-up this detection seems more difficult. The main vulnerability comes from the fact that the receiver may not have a good-enough clock reference against which to check the signal times of arrival to ascertain if they arrive in delay. The receiver may have been switched off for hours, days or weeks, and the receiver clock bias may be too large. For example, current Temperature-Controlled Cristal Oscillators (TCXO) in smartphone devices can have a stability of up to 0.5 ppm (parts per million) (i.e. they can drift 0.5 seconds in a million seconds, or 0.5 microseconds in a second) [104]. In some few milliseconds (some hundred km at light speed), or even microseconds (some hundred metres at light speed), an attacker could selectively replay the signal satellites with a coherent delay leading to a coherently wrong position. Attacks in these situations cannot be protected through any signal-only measures as NMA or SCE. We cannot assume the existence of method that authenticates a fix based only on radionavigation signals against all types of known attacks. In our help, there are other systems and protocols available that provide external synchronisation:
PTP (Precise Timing Protocol), defined in the IEEE-1588 Standard and providing nanosecond-level synchronisation [105] [106] [107]17. Mobile communication network standards as or 4G LTE networks, expected to provide time authentication to user terminals in the order of the microsecond. Other radiofrequency systems more difficult to spoof, transmitting a signal to which the receiver can be synchronised (e.g. e-Loran), that can provide time transfer in the nanosecond level. An external frequency standard signal connected to the receiver and providing a time reference, or a second clock reference embedded in the user terminal.
17 It must be noted that the timing sources that provide timing by any protocol can also use GPS/GNSS receivers, and therefore be also subject to spoofing. This is left out of the scope of the thesis. In any case, is not obvious to attack a highly accurately synchronised network, even if it uses GPS, while remaining unnoticed.
227 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
A previously authenticated time reference from the same receiver clock that is propagated to the current time with an associated uncertainty. If the receiver is using an accurate clock as e.g. a Chip-Scale Atomic Clock (CSAC), this process is feasible with low accuracy degradation.
Based on this idea, the following section describes algebraically some methods to detect such spoofing attacks. They are very simplified and more sophisticated methods based on the same or similar principles are possible. This is left for further work.
GENERAL DESCRIPTION
The purpose of this method is to authenticate pseudoranges by adding time and geometrical constraints. The ones analysed here are the receiver clock bias and the receiver height. These methods do not assume any previous tracking of the authentic signals. Therefore, they can be used for snapshot positioning or at signal acquisition.
External Receiver Clock Reference
This method is based on constraining the receiver clock bias through another time synchronisation source. The method assumes the use of an accurate time reference provided through any of the several other protocols and systems using an authenticated point-to-point two-way link, unlike satellite one-way radionavigation signals, as the ones mentioned above, or by a trusted accurate clock as a CSAC. The user terminal will be able to time-tag the computed measurements with the external time reference in order to constrain the position and time solution given originally by the GNSS measurements. In other words, the receiver does not need to compute the bias because it is known.
A user terminal receiver can obtain an external time reference from a network server or base stations through an authenticated communication channel, as follows:
It can send a time-tagged request to a nearest base station/server of a mobile network that is synchronised with the same time reference (e.g. GPS or Galileo time) as that used for navigation, or a time reference whose offset is known to that used for navigation. An authenticated channel is required. The server provides an accurately time-tagged message. The communication protocol allows the User Terminal (UT) synchronisation by for example determining the packet time of departure plus estimating the delay of
228
a round-trip communication. Any other standard accurate synchronisation protocols can be used, as the external synchronisation process is not the core of the method.
By time tagging the reference time with the local time, the UT is able to determine the time bias between the local clock and the time reference. In addition, the system needs that:
The pseudorange measurements used must come from satellites that include unpredictability and authentication features as NMA, SCE, SSSC watermarking [20] or others. That means that, if their signals are spoofed, they need to be replayed to be correct by verifying a digital signature, a MAC, decoding a cyphered stream, receiving the unpredictable symbols from an assistance channel, or any other means as described in Chapter 3. This makes the only attack possible to be the signal replay attack, in which case, this set of pseudorange measurements will incorporate a delay introduced by the attacker. The data/codes modulated in the signals from which these measurements are computed, have been authenticated by the authentication method proposed in the signal, e.g. digital signatures or message authentication codes, or through assistance data, e.g. verifying that the unpredictable demodulated symbols or chips correspond to those received by the assistance server, and considered as authentic. The data used to compute the satellite positions and times, is authentic, and optionally the data to model the propagation errors if these error models are used (e.g. Klobuchar ionospheric correction).
Therefore, signals incorporating the NMA solution proposed in Chapter 3 are good candidates, as they contain some of the unpredictable symbols transmitted every 1.5 seconds, and their per-satellite TBA is only 10 seconds (TBA would become irrelevant if an assistance server sends the unpredictable symbols through an authenticated channel).
Figure 77 shows a time-aided terminal under a meaconing attack. The user terminal (UT) is receiving unpredictable signals from navigation satellites. It time-tags the received signals with 푡푟푥,푚푒푎푠, the local time reference. The UT is also synchronised with an external synchronisation reference, shown as an external block in the figure. The external synchronisation link allows to determine the actual offset b between 푡푟푥,푚푒푎푠 and 푡푚푒푎푠,
229 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION the time at which the measurements were actually received. If the receiver is not under any signal replay attack, the bias of the position solution will coincide with the bias from the external source. The figure shows the case whereby an attacker is replaying the signals with a fixed delay D (necessary to perform the attack; in an intelligent spoofing attack, the signals may incorporate a variable delay per satellite in addition to D, leading to a coherently spoofed position. For simplicity, these variable delays have not been considered in the illustration). If the receiver is receiving replayed signals, b'=b+D ≠ b, so it can detect spoofing thanks to the external reference.
Figure 77 - User terminal, time reference and spoofer External Receiver Position Height Reference
The principal constraint proposed here is an externally estimated height, e.g. through an approximate position of the user in a given reference frame and/or a Geographical Information System (GIS), or Digital Elevation Model (DEM), Digital Surface Model (DSM) or Digital Terrain Model (DTM). Other altitude metrics, as e.g. barometers used for aviation, are possible.
As no satellite signal can be received from underground, the satellite measurements cannot by themselves constrain the height direction. There will be plausible (low- residual) solution with replayed signals at heights below the actual one. If measurements were received from satellites from both directions of the three axes (e.g. North, East, Down or NED) this check would not be necessary, as a delay in the measurements would lead to no plausible solution.
230
The use of the height helps constrain the solution. It may be comparable to having a satellite at the Earth centre whose pseudorange is known, and corresponds to the height (from the Earth centre, in this case; other reference points are possible) given by the external sensor or model. The concept is illustrated in Figure 78. It presents a two- dimensional example of the reduction of the plausible space of solutions due a priori height and clock bias estimations.
Figure 78 - Reduction of solution space with height estimation The figure presents two satellites located at distances R1 and R2 of the receiver (P). D represents the delay for the spoofer to estimate and replay the signal. Without the height estimation, the space of possible spoofed solutions is the purple area: The spoofer could locate the receiver in any point of this area (P'), without the receiver having a way to notice.
A navigation solution using measurements generated from rebroadcast signals would fall out of the space of plausible data-authenticated navigation solutions and therefore would be detected as a wrong solution. Therefore, if there is a plausible solution consistent with the additional reference time, the obtained measurements, and the imposed height constraint, we can conclude that, with a very high likelihood, a replay attack has not been performed, or the position has not been displaced more than a certain distance in the order of the accuracy of the measurements and the additional time reference (e.g. a time source with a 1-μs accuracy would lead to an uncertainty in the order of 300m).
Other Constraints
Similarly, additional constraints that may be imposed on the solution are:
231 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Distance to a reference station or stations from a network, installed for communication (e.g. mobile network base stations) or navigation and positioning purposes, as RTK (Real Time Kinematic) networks. Other GIS information constraining the type of application under use, as for example the elimination of non-passable areas for vehicular positioning applications [108].
IMPLEMENTATION DESCRIPTION
This section describes some implementations of the method. Measurement errors (e.g. multipath, ionosphere or receiver noise) are aggregated to a single error term 휺, without precluding the implementation of error estimation according to standard navigation models as those mentioned several times throughout the thesis.
The following sections present authenticated PVT navigation equation systems.
Navigation Solution without Estimation of Receiver Clock Bias and with Height Verification
We assume that the receiver clock bias is provided from an external source and is authenticated. We name it brx,ref in the remaining steps. The method assumes that brx,ref is the bias at the measurement reception time. If not, the error will depend on the receiver clock drift. For example, an error of 1ms in a clock with a 1ppm drift will lead to a bias error of 1ms/106 = 1ns, or 30 cm.
The user terminal selects the pseudorange measurements of N satellites transmitting unpredictable signals, N≥ 3. These pseudorange measurements are called ρi, i=1,..,N.
The user estimates the range measurements by subtracting brx,ref to the pseudoranges, and any other ephemeris or propagation (ionosphere and troposphere) errors 휀푖 that are known to the user, either from the satellite navigation message or from an assisted data channel.
푟푖 = 휌푖 − 푏푟푥,푟푒푓 − 휀푖 (D.1) i=1,..,N. N≥ 3 where 푟푖 is the range of satellite i, and 휀푖 incorporates all the pseudorange errors apart from the receiver clock bias: satellite clock, ionosphere, troposphere, multipath and
232
receiver noise. These errors are modelled through data that is already authenticated, or bounded through error model statistical distributions.
The UT computes a user position with the range measurements through standard methods (Taylor linearization, Kalman filters [95], Least squares if more than three measurements, etc.). In our particular case, the receiver clock bias, which is the fourth unknown, does not need to be estimated, and instead the external bias estimation brx,ref is used. The next steps are equivalent to standard position estimation methods (e.g. [5], Ch.
4). We start with an a-priori estimation of the state vector X0=(x0, y0, z0). The bias, as already determined by brx,ref, is not part of the state vector.
Based on the reference time 푡푟푥,푚푒푎푠 + 푏푟푥,푟푒푓, in which measurements 휌푖 are time- tagged, we predict the measurements 휌̂푖 that would be obtained for each satellite i.
휌̂푖 = |S푖 − 푋0| + 푏푟푥,푟푒푓 + 휀푖̂ (D.2) where S푖 is the satellite position vector at the estimated transmission time, X0 is the receiver estimated position and 휀푖̂ is the estimated measurement delay error. We then compute the difference between the received measurements 휌푖 and the predicted measurements:
δ휌푖 = 휌푖 − 휌̂푖 (D.3)
We compute the geometry matrix H as an [i x 3] matrix, without the 4th column of 1s usually employed for navigation to calculate the bias. The state vector is updated through the standard least-squares iterations.
퐻[푖 푥 3] = [−푒푖] (D.4)
δX = (퐻푇퐻)−1퐻푇δ휌
푋 = 푋0 + 훿푋 (D.5) where 푒푖 is the unit vector pointing from X0 to the satellite i. We iterate several times by using X as 푋0 for the next iteration, until the solution converges to a position X=(x,y,z). The position, in ECEF coordinates, is converted to latitude, longitude and height geodetic coordinates through the required translation matrix: Xgeod=(lat, long, h).
233 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
Now, the receiver will use estimation of the position height from an external source. This estimation is called href in the following steps. Now, the receiver compares the height of the estimated position h with href. If they differ more than a certain amount H_THR, then the position is considered as not authenticated.
| href – h| < H_THR (D.6)
The value of H_THR will depend on the probability of missed detection (PMD) and probability of false alarm (PFA) used in hypothesis testing, in which one hypothesis (H0) assumes that there is no spoofing, and another one (H1) assumes there is. The distribution errors are characterised and then the threshold is set to accept a maximum PFA. If no accurate measurement of the user position height can be obtained, href can be calculated as the minimum height for the user to be in or above the earth surface expressed in a given reference frame. The threshold (H_THR) shall be adjusted to the desired missed detection and false alert probabilities of the application, the uncertainty associated to the position and external height estimations, and satellite geometry as reflected in the HDOP.
The use of height is important as otherwise the delayed measurements generated by an attacker may be used to find a plausible solution with delayed (i.e. longer) ranges at a lower height, as shown in Figure 78. To ensure that this is not occurring in other directions, the receiver can check that the geometry does not allow ranging measurements being increased while still leading to a coherent (i.e. low residual error) position. Having satellites at low elevations will help constrain the solution. In addition, common biases that are not part of the clock bias (e.g. receiver filters, non-modelled ionospheric delay) will introduce a position error. This error may be assumable for many applications requiring authentic positioning.
Including the Height as an Additional Pseudorange
Another possible method is to consider the height as an additional pseudorange source in the navigation equations, and look at the solution residuals. The potentially higher error of the external height estimation can be treated through the appropriate measurement weighting. Weighed Least Squares estimation method is explained in detail in Chapter 11 of [109], for example, and is common practice in GNSS. In this case, if we have N measurements, the component n+1 of the measurement vector 휌 would be the
234
determined by the height model, and the 'pseudo-satellite' position can be at the Earth centre, or Cartesian coordinates (0,0,0).
휌̂푛+1 = |푋0| + 푏푟푥,푟푒푓 (D.7)
휌푛+1 = 퐹(푚표푑푒푙, 푋0) + 푏푟푥,푟푒푓 (D.8)
where 흆̂풏+ퟏ is the estimated range from (0,0,0). 퐹(푚표푑푒푙, 푋0) provides that range from the height model, at a given , 푋0. The following equations present the weighted least squares standard steps, when the '0,0,0' pseudo-satellite is used.
훿휌푛+1 = 휌푛+1 − 휌̂푛+1 (D.9)
훿푋 = (퐻푇푊퐻)−1퐻푇W훿휌 (D.10)
The last row of H will include the reverse-signed unit vector of the (0,0,0) pseudo- satellite. If the solution converges to a position at the adequate height, it can be flagged as authentic. If not, it can be flagged as not authenticated. If an overdetermined solution is used, the measurement residuals |퐻훿휌 − 훿푋| can be computed and if they are above a given threshold, then the solution can be flagged as not authenticated. Similar hypothesis testing as abovementioned can be performed.
Removing the Height Computation from the Satellite Positioning Solution
Another approach similar to this one, but perhaps simpler, would be to remove the height unknown and compute just the two horizontal components. For each iteration, the height would be taken from the height model. Combining this approach with the provision of the clock bias from an external source makes that only two unpredictable signals are sufficient to protect against replay.
Standard 4-Dimensional State Vector and Bias Threshold Comparison
Another approach is to use the standard navigation equations, solving the 3-dimensional position and the bias, and then compare the difference between the obtained bias minus brx,ref, with a threshold, equivalently to the proposal described after Figure 77. If the spoofer is falsifying the position while maintaining the bias as correct, then the height of the position solution needs to be verified, as per Equation (D.8).
235 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
|brx,ref – b| < B_THR (D.11)
CONCLUSIONS
The purpose of this appendix is to study the provision of snapshot authentication. It serves as an epilogue of the technical and scientific work of this thesis, by merging the two principal research areas.
Robustness against attacks taking place at the switch-on and acquisition phase is more difficult to achieve than when authentic signals are tracked. The case of snapshot positioning, and/or A-GNSS positioning, is similar. If no trusted time reference is available, snapshot positioning can always be subject to an attack in which the attacker has pre-recorded a snapshot and re-broadcasts it later.
The solutions proposed are therefore based on the knowledge of an accurate and authentic external reference time. Accurate timing protocols (as e.g. PTP) that can produce up to sub-ns timing accuracy, can be used to externally synchronise the receiver.
This appendix has focused on the PVT domain, assuming that the measurements coming from the signal processing block are based on unpredictable and verifiable satellite signals. In this case, an attacker can only delay the signals. If the clock bias is known, at the time the measurements are time-tagged, the attacker can only make the pseudoranges bigger, which poses some constraints for coherent attacks. Another constraint proposed to detect attacks is to use height, from either a digital height model, GIS information, a barometer, or more simply the geoid, assuming that the user is on the earth surface. Depending on the input, the method will be more or less resilient.
Based on these two constraints, some methods to compute an authenticated position are proposed. The methods are based on incorporating timing and geometric constraints in the navigation solution.
We can conclude that, by applying these (and other) methods, robustness when signals are acquired by a receiver with a stable and trusted reference clock can be high sufficient with signal-only measures, especially if combined with geometrical constraints. Adding other sensors (e.g. INS) to the positioning engine can nothing but improve the PNT resilience in a complementary way.
236
Appendix E. Acronyms
3GPP 3rd Generation Partnership Project
AAU Aalborg University
ADC Analog to Digital Converter
ADKD Authentication Data and Key Delay
AER Authentication Error Rate
AES Advanced Encryption Standard
AGC Automatic Gain Control
A-GNSS Assisted GNSS
A-GPS Assisted GPS
AOA Angle Of Arrival
APNT Alternative Positioning, Navigation and Timing
AWGN Additive White Gaussian Noise
BER Bit Error Rate
BGD Broadcast Group Delay
BOC Binary Offset Carrier
BPSK Binary Phase Shift Keying
BSI British Standards Institution
C/N0 Carrier to Noise density ratio
CDMA Code Division Multiple Access
CET Central European Time
CMAC Cipher based Message Authentication Code
CPU Central Processing Unit
CRC Cyclic Redundancy Check
CRLB Cramér Rao Lower Bound
CS Commercial Service
CSAC Chip-Scale Atomic Clock
237 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
CT Coarse Time
CW Continuous Waveform
DEM Digital Elevation Model
DME Distance Measuring Equipment
DOP Dilution Of Precision
DOW Day Of Week
DSA Digital Signature Algorithm
DSH Digital Signature Header
DSID Digital Signature ID
DSM Digital Signature and Message
DSM Digital Surface Model
DSRC Dedicated Short-Range Communications
DSSS Direct Sequence Spread Spectrum
DTM Digital Terrain Model
ECDSA Elliptic Curve Digital Signature Algorithm
ECEF Earth Centred Earth Fixed
EDBS External Data Broadcast Service
EGNOS European Geostationary Navigation Overlay Service
ERIS External Regional Integrity Service
FDMA Frequency Division Multiple Access
FEC Forward Error Correction
FER Frame Error Rate
FFT Fast Fourier Transform
GBAS Ground Based Augmentation System
GDOP Geometric Dilution Of Precision
GEO Geostationary Earth Orbit
GIS Geographic Information System
GLONASS GLObal NAvigation Satellite System
238
GMS Ground Mission Segment
GNSS Global Navigation Satellite System
GPS Global Positioning System
GPST GPS Time
GSC European GNSS Service Centre
GST Galileo System Time
H-KROOT Header and Root Key
HMAC Hash-based Message Authentication Code
HS Health Status
ICD Interface Control Document
IEC International Electrotechnical Commission
IF Intermediate Frequency
IFFT Inverse Fast Fourier Transform
IIR Infinite Impulse Response
INS Inertial Navigation System
IOD Issue Of Data
IODnav Issue Of Data - Navigation
IRNSS Indian Radio Navigation Satellite System
ISO International Standards Organisation
IT Information Technologies
J/N Jamming to Noise
KPI Key Performance Indicator
LEO Low Earth Orbit
LMS Land Mobile Satellite
LSB Least Significant Bit
LTE Long Term Evolution
MAC Message Authentication Code
MAC-K MAC and Key
239 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
MEMS Micro-Electro-Mechanical Systems
MEO Medium Earth Orbit
MPT Maximum Predictable Time
MSAS Multi-functional Satellite Augmentation System
MSB Most Significant Bit
NA Number of Authentication bits
NED North East Down
NIST National Institute of Standards and Technology
NMA Navigation Message Authentication
NN Number of Navigation bits
NNA Number of Navigation and Authentication bits
NSA National Security Agency
OS Open Service
OTAR Over-The-Air Rekeying
PAM Pulse Amplitude Modulation
PDOP Position Dilution of Precision
PKI Public Key Infrastructure
PLL Phase Locked Loop
PNT Positioning, Navigation and Timing
PPM Parts Per Million
PRN Pseudo Random Number
PRS Public Regulated Services
PSK Phase Shift Keying
PTP Precise Time Protocol
PVT Position, Velocity and Time
QZSS Quasi-Zenith Satellite System
RAIM Receiver Autonomous Integrity Monitoring
RF Radio Frequency
240
RMS Root Mean Squared
RSA Rivest, Shamir and Adleman
RSS Receiver Signal Strength
RTK Real Time Kinematics
SAASM Selective Availability and Anti-Spoofing Module
SBAS Satellite Based Augmentation System
SCE Spreading Code Encryption
SCER Security Code Estimation and Replay
SDR Software Defined Radio
SHA Secure Hash Algorithm
SIS Signal in Space
SSSC Spread Spectrum Security Codes
SVID Space Vehicle ID
TACAN Tactical Air Navigation System
TBA Time Between Authentications
TCXO Temperature-Controlled Cristal Oscillator
TDMA Time Division Multiple Access
TDOA Time Difference Of Arrival
TDOP Time Dilution of Precision
TESLA Timed Efficient Stream Loss-Tolerant Authentication
TLM Telemetry
TOA Time Of Arrival
TOW Time Of Week
TTFAF Time To First Authenticated Fix
TTFF Time To First Fix
UERE User Equivalent Range Error
ULS Up-Link Station
USR Unpredictable Symbol Ratio
241 SNAPSHOT AND AUTHENTICATION TECHNIQUES FOR SATELLITE NAVIGATION
USRP Universal Software Radio Peripherals
UT User Terminal
UTC Universal Time Coordinated
VOR VHF Omni-directional Radio Range
WAAS Wide Area Augmentation System
WGS84 World Geodetic System 1984
WLS Weighted Least Squares
WN Week Number
XOR eXclusive OR
242
Appendix F. Published Papers
Thesis title: Snapshot and Authentication Techniques for Satellite Navigation
Name of PhD student: Ignacio Fernández Hernández
Name and title of supervisor and any other supervisors: Prof. Torben Larsen. Prof Kai Borre.
List of published papers:
Paper 1: I. Fernández Hernández, “Authentication: Design Parameters and Service Concepts,” Proceedings of the European Navigation Conference, 2014.
Paper 2: I. Fernandez-Hernandez, V. Rijmen, G. Seco-Granados, J. Simón, I. Rodríguez, J.D. Calle, “Design Drivers, Solutions and Robustness Assessment of Navigation Message Authentication for the Galileo Open Service,” in ION GNSS+ 2014, 2014.
Paper 3 (pending): I. Fernandez-Hernandez, V. Rijmen, G. Seco-Granados, J. Simón, I. Rodríguez, J.D. Calle, "A Navigation Message Authentication Proposal for theGalileo Open Service", The Journal of the Institute of Navigation, Date to be defined.
"This thesis has been submitted for assessment in partial fulfilment of the PhD degree. The thesis is based on the submitted or published scientific papers which are listed above. Parts of the papers are used directly or indirectly in the extended summary of the thesis. As part of the assessment, co-author statements have been made available to the assessment committee and are also available at the Faculty. The thesis is not in its present form acceptable for open publication but only in limited and closed circulation as copyright may not be ensured.".
243