Inside GNSS Media & Research

JUL-AUG 2019

Issue link: https://insidegnss.epubxp.com/i/1148308

Contents of this Issue

Navigation

Page 29 of 67

30 Inside GNSS J U L Y / A U G U S T 2 0 1 9 www.insidegnss.com WORKING PAPERS multiple services, integrating smartcards and HSM as part of the user segment. One particular challenge is to identify the least common multiple requirements in a multi-application GNSS scenario. Diff erent applications entail diff erent requirements, particular- ly for these major drivers: • Level of required Robustness; • Security Protocol features: detection only or detection and mitigation (secure navigation); • Security Protocol performances such as time to authentica- tion, rekeying delay, etc.; • Security Protocol Integrity, availability and accuracy performances; • Achievable security, and • Cost and performances impact at receiver. Integrating the needs of safety critical and mass market applications with a single service and unique receiver hard- ware architecture can become very challenging both on sys- tem and receiver design. is article presents an innovative concept of Multi-Tier Signal Authentication (MTSA) for GNSS, introducing diff erent services and hardware implementations, which could leverage the integration of smartcards and HSM in the GNSS industry civilian domain. e main objective is to attempt to defi ne a service that can satisfy multiple user requirements for diff erent applications. Being only a concept proposal, consolidated service implemen- tation details as well as results are le for future work. FIGURE 2 Graphical concept of HW Classes. FIGURES 3 AND 4 A GNSS module Class 2 example (Left). A Class 2 mobile phone example (Right). Main Design Drivers e idea of the Multi-Tier Signal Authentication (MTSA) is to allow the implementation of diff erent user services that can satisfy diff erent requirements. e main requirements discrimination is: • Authentication latency and authentication performances; • Requirement for authentication only, or authentication and robust navigation (navigation under attack); • Need of security module in the receiver, to support sym- metric services; • Availability of network connectivity (aiding channel), and • Option to defer the security to an external component (e.g smartcard), in order to maintain the current GNSS chip cost and design. As baseline, the MTSA concept is designed to provide authen- tication services to three main classes of hardware ( Figure 2 ): • Class 1, GNSS receivers with no specifi c security hardware: ◉ A) Unconnected devices with no security module. ey use Asymmetric services or services that achieve asymmet- ry through delayed key release. ◉ B) Connected Devices with no security module, ser- ver-side processing (transmission of RF samples to a cloud service). Server-side processing is out of the scope for this article but it is mentioned to highlight that Class 1 devices could support such service. • Class 2: ◉ Low end hardware security module (e.g. ISO7816 smart- card or chip-based HSM). ey use symmetric key services, which are faster but require key protection. Connection is required for rekeying if needed or when scheduled, unless suffi cient bandwidth is available in the broadcast signal. • Class 3: ◉ High end hardware security module. ey allow navi- gation and timing in hostile (under attack) scenario. ey do not need connection; rekeying can be performed over the air. In order to achieve this broad coverage of requirements a sche- me is proposed that requires two channels, one with public available pseudorandom noise (PRN) codes carrying data that can be processed by all users (as GPS C/A or Galileo OS), and, a second channel that allows all signal-based authentication services implementation at code level. Class 2 devices assume that the signal processing of the aut- hentication signal is performed inside the smartcard or HSM. is is achievable with modern technology, and it is expected that performances of security hardware will improve exponen- tially in the future. In order to send the minimum amount of data to the smartcard and reduce the processing on its side, it is assumed that the signal is acquired for example on an open signal component and there is knowledge of the authentica- tion information location both in code phase and the signal complex arm. For example, a hypothetical design could foresee an open signal transmitting on the in phase component, and the aut- hentication signal on the quadrature part. Once the code phase and Doppler of the open signal are resolved by the receiver, the precise samples of the authentication code in the quadrature

Articles in this issue

Links on this page

view archives of Inside GNSS Media & Research - JUL-AUG 2019