oscar pozzzobon technical director, qascom ion gnss 2011, september 23, portland, us
TRANSCRIPT
![Page 1: Oscar Pozzzobon Technical Director, Qascom ION GNSS 2011, September 23, Portland, US](https://reader035.vdocuments.us/reader035/viewer/2022072013/56649e615503460f94b5c319/html5/thumbnails/1.jpg)
Oscar Pozzzobon
Technical Director, Qascom
ION GNSS 2011, September 23, Portland, US
![Page 2: Oscar Pozzzobon Technical Director, Qascom ION GNSS 2011, September 23, Portland, US](https://reader035.vdocuments.us/reader035/viewer/2022072013/56649e615503460f94b5c319/html5/thumbnails/2.jpg)
September 23 2011, Portland, US
Where are we?
GPS no civilian authentication. Egnos, no authentication, Galileo CS might not provide a ranging signal and Galileo SOL has been designed for different purposes, so we will have to rely on user segment authentication services for a while.
The GNSS authentication community has dedicated the last 10 years to develop complex signal spoofing and signal authentication techniques, but it’s time to get back to the problem: how do we authenticate PVT? The GNSS community wants a clear answer for every application.
Whilst following the security life cycle, PVT spoofing threats and mitigation can now be categorized to begin a process of receiver certification for PVT authentication.
![Page 3: Oscar Pozzzobon Technical Director, Qascom ION GNSS 2011, September 23, Portland, US](https://reader035.vdocuments.us/reader035/viewer/2022072013/56649e615503460f94b5c319/html5/thumbnails/3.jpg)
September 23 2011, Portland, US
From an hypothetical classification of attacks…
![Page 4: Oscar Pozzzobon Technical Director, Qascom ION GNSS 2011, September 23, Portland, US](https://reader035.vdocuments.us/reader035/viewer/2022072013/56649e615503460f94b5c319/html5/thumbnails/4.jpg)
September 23 2011, Portland, US
Towards a standardization of security requirements for commercial receivers? (example)
Signal Hardware Software PVT Data
Level 1Anti Spoofing based on
position solution algorithmsIntegration of a trusted
clockfirmware upgrade
protection
Requires data authentication
Data crypto key stored in Black
memory
Level 2
Anti Spoofing based on position solution algorithms
Use of anti-tamper coating
firmware upgrade protection
Requires data authentication
signal processing techniques (P(Y)
correlation, SSSC, SAS)
Integration of a trusted clock
Data crypto key stored in Black
memory
Level 3
Requires ranging from signal with Navigation
Message Authentication (NMA)
secure key storage (red memory)
firmware upgrade protection
Requires data authentication
Crypto accelerator (red memory) trusted boot ROM
Data crypto key stored in Red
memorytrusted clock
Level 4
Requires ranging from signal with Spreading Code
Encryption (SCE)
Tamper detection HW firmware upgrade
protection
Requires data authentication and
encryption capabilityRequires red + black
data Zeroization
secure key storage (red memory)
trusted boot ROMData and signal keys
stored in Red memory
Requires secure code replica and correlators
crypto accelerator (red memory) with secure
random numbertrusted clock
![Page 5: Oscar Pozzzobon Technical Director, Qascom ION GNSS 2011, September 23, Portland, US](https://reader035.vdocuments.us/reader035/viewer/2022072013/56649e615503460f94b5c319/html5/thumbnails/5.jpg)
September 23 2011, Portland, US
Conclusions
While the research will continue towards new proposals for signal authentication, the industry should have a plan B for the next 10 years, developing algorithms at receiver level.
A US-EU task force should be created to give clear responses (security requirement standards) to the civilian GNSS community.