Tag: encryption

Tests begin of Galileo’s OSNMA signal authentication service

In a first for any satellite navigation system, Galileo has achieved the first position fix based on navigation signals carrying authenticated data, according to the European Space Agency.

Galileo’s Open Service Navigation Message Authentication (OSNMA) is intended as a way to combat malicious spoofing of satnav signals.

OSNMA receivers successfully calculated an OSNMA-protected position fix after Galileo satellites started transmitting authentication data at 15:28 UTC on Nov. 18, 2020. The first tests used eight Galileo satellites for around two hours on Nov. 18. Tests have continued ever since, for intermittent periods, and will continue over the next months ahead of a public observation phase.

The first authenticated signal position, velocity and timing fixes were made using a total of eight Galileo satellites for around two hours on Nov. 18, 2020. The tests represent a first proof-of-concept for an eventual operational service offering positioning with authenticated data to users. (Image: ESA)

Pioneering a long-awaited service

The Galileo OSNMA authentication mechanism allows GNSS receivers to verify Galileo information, making sure that received data are indeed from Galileo and not modified in any way.

“Ensuring the validity of positions elaborated by GNSS is one of the main challenges before addressing an entirely new set of applications demanding dependability and resilience,” said Matthias Petschke, director of space at the European Commission, DG DEFIS. “Galileo is now set on course to deliver on this highly anticipated feature and has many more novel features in store for the coming years.”

Testing is taking place at ESA’s Navigation Laboratory at ESTEC in the Netherlands, the same site where the first Galileo positioning fix took place in 2013.(Photo: ESA)

Increased robustness

OSNMA test signals are being broadcast by the Galileo constellation using the spare bits from the current navigation message, therefore not impacting the legacy OS receivers implementing the current OS Signal-In-Space Interface Control Document (OS SIS ICD).

“Galileo’s Open Service Navigation Message Authentication is one of its key differentiators,” said Rodrigo da Costa, executive director of the European GNSS Agency. “The additional robustness that it will provide to the Galileo signal will be critical for many applications, particularly those where security and trustworthiness are a priority, making the OSNMA a key component in any resilient PNT solution.”

OSNMA works on a comparable basis to everyday encryption, where sending a digitally signed document involves both sender and recipient using compatible cryptographic keys (private and public) to validate the document’s source of origin.

“Up until now, as a navigation satellite disseminates navigation and timing data, there is no way of confirming these data are indeed coming from their apparent originator,” explained Paul Verhoef, director of navigation at the European Space Agency. “As a result, the data could be falsified, a phenomenon known as spoofing, where corrupt false signals mislead receivers about their position, misleading their users in turn, with potentially serious consequences.”

An ESA Navigation Directorate team at the ESTEC technical centre in the Netherlands worked with their European GNSS Agency (GSA) counterparts at the twin Galileo Control Centres in Italy and Germany and the Galileo Service Centre (GSC) in Spain to develop and test the OSNMA.

Next steps

Upon successful completion of the internal testing phase, a public observation phase will begin, in which the OSNMA signal will be publicly accessible. In preparation for this phase, the OSNMA user Signal-In-Space Interface Control Document (OSNMA SIS ICD), receiver implementation guidelines, and the necessary cryptographic materials will be published. This will allow receiver manufacturers and application developers to test and prepare their products.

During the public observation phase, feedback will be gathered from users, leading to the consolidation of the service.

Testbed vehicle by ESA’s Navigation Lab. (Photo: ESA)

February 11, 2021
Microchip introduces timing GPS with embedded M-code receiver
New SyncServer S650 M-Code secures military communication systems, radar and networks reliant on GPS signals

Photo: Microchip

Threats from intentional jamming and spoofing of GPS signals, as well as cybersecurity risks to critical infrastructure, demonstrate the need for powerful and secure time and frequency systems that ensure continuing operability and performance.

Microchip Technology’s SyncServer S650 M-Code time server has received approval from the U.S. Air Force GPS Directorate of the Los Angeles Air Force Base for use in support of military communication systems, radars and networks.

M-code, an encrypted military signal broadcasted in GPS frequency bands, is required by congressional mandate for mission critical Department of Defense (DOD) applications in hostile environments. Microchip’s SyncServer S650 M-Code equipped time and frequency server provides a secure, accurate, flexible platform for synchronizing mission-critical electronic systems and instrumentation.

For DOD programs requiring jam-resistant, encrypted time and frequency signals from the GPS military M-code Precise Positioning Service (PPS), the SyncServer S650 M-Code is a secure time and frequency instrument with a fully integrated M-code GPS receiver.

“As the first time and frequency instrument enabling DOD compliance for M-code-based GPS systems, this technology demonstrates Microchip’s continuing commitment and investment in the security of time and frequency systems,” said Randy Brudzinski, vice president, Frequency and Timing Solutions business unit. “This time server represents a new level of security hardening built on Microchip’s proven commercial SyncServer S650 time server that provides extreme timing accuracy, security and flexibility.”

The SyncServer S650 M-code equipped time and frequency instrument is a rack mounted server device that synchronizes to the atomic clocks aboard GPS satellites via M-code. The S650 M-code leverages new technology to provide enhanced anti-jamming protection and further hardening against spoofing, providing greater accuracy, and improving operator ease-of-use for key loading.

Harder to jam than commercial CA-Code GPS, M-code provides a more secure signal than the commercial CA-Code or SAASM P(Y) signal, with greater accuracy. The instrument also is easier for operators to load crypto keys.

Staff Sgt. Daniel Pennington, a flight engineer assigned to B Co “Big Windy,” 1-214th General Support Aviation Battalion, takes in his ‘office’ view from the ramp of his CH-47 Chinook while flying over the island of Cyprus on Jan. 14, 2020. (Photo: U.S. Army/Maj. Robert Fellingham)

The SyncServer S650 M-Code can utilize Microchip’s FlexPort technology for multiport, user definable output signal configurations for Inter-Range Instrumentation Group (IRIG) timecodes, pulses and a variety of signal types essential for military communication, radars and network system synchronization. This is coupled with Microchip’s NTP Reflector technology for robust security, accuracy and reliability of network-based time services such as Network Time Protocol (NTP) and Precision Time Protocol (PTP). Other features include:
- Four standard GbE ports, all with patented NTP hardware time stamping, with two additional 10 GbE ports optional
- Contains most popular timing signal inputs/outputs standard in the base timing I/O module (IRIG B, 10 MHz, 1PPS)
- Web-based management with high security cipher suite
- Rubidium atomic clock or OCXO oscillator upgrades
- Superior 10 MHz low phase noise options
Microchip has been delivering the SyncServer S650 to synchronize business critical and mission critical operations, across all industry segments, since its commercial introduction in 2016.
July 30, 2020
The role of GNSS in driverless cars
Authenticated localization in driverless cars

Growing awareness of the vulnerabilities of GNSS signals — weak, unencrypted and easily jammed or spoofed — have made GNSS less important to steering the driverless vehicle. What’s up with that?

Extensive visual map databases are being created that, when coupled with cameras, radars and lidars on the vehicle and processed by artificial intelligence (AI) algorithms, enable the driverless car to be steered much the way humans drive. Pattern recognition processing in the vehicle allows it to “read” street signs and recognize landmarks, registering its position on the map.

This is the way a person drives in his or her home town, where they always know their orientation and don’t need GNSS. The AI processing “brain,” with access to huge map databases, either through local storage or a network connection, will always be in its familiar home environment: continuously knowing its own position and properly oriented for navigation.

So, will GNSS become unnecessary in the car of the future? Probably not.

First, no one method of navigation is foolproof, and today, GNSS is our primary method of navigating our cars. It is a cost-effective, accurate way of determining position in real time, and with the integration of inertial navigation sensors to handle cases when GNSS is intermittently unavailable, it is improving.

Second, it is not just the car itself that needs to know its location for navigation, but also others outside the car. Ride-sharing apps like Uber and Lyft, car-sharing, usage-based insurance apps, dynamic toll charging, and parking apps all depend on knowing where the car is at all times. GNSS offers sufficient accuracy for all these apps by providing location coordinates. Therefore, a GNSS receiver will most likely remain in the car.

The case for jamming and spoofing

Recall, however, that one of the weaknesses of GNSS is its open, unencrypted format. It is becoming increasingly easier to spoof these signals. Car-sharing, usage-based insurance and dynamic toll charging apps all create a monetary incentive for fraud that can be implemented with a spoofer. For example, a car in a car-sharing network can report a fake position indicating that it is safely parked in a secure area — while in reality, a thief is busy driving it away.

(Image: Orolia)

Let’s assume that all wireless connections to and from the car are secure. This is a reasonable assumption, although recently there have been demonstrations of carjacking via unsecure remote links. Standard SSL encryption, similar to what is used to enter credit card information on the internet, works well here. We have both the awareness and the technology now to prevent such carjackings from ever reoccurring.

However, even if communication links are secure, a GNSS spoofer in the car can fool the GNSS receiver into reporting a fake “safe” position right as it is being stolen. The same is true for insurance or toll apps. And the fraud does not have to be sophisticated. A simple, low-cost jammer can deny proper position just long enough to skirt payment. A secure location method is needed.

Other signals for localization

What would an ideal signal for localizing a driverless car look like?
- It needs to be much stronger than GNSS so it is not easily jammed.
- It needs to be encrypted so it cannot be spoofed.
- It must be ubiquitous, available worldwide.
- It must be reliable and robust — with 99.999% availability or better.
- It must be practical and priced for the mass-market automotive application.
Though accuracy is always important, the signal used for localization does not have to be as accurate as GNSS is today. Accuracy to 10s of meters is sufficient for all these applications needing fraud protection since it would not be used for steering the car, but rather, only localization. It can also be used in tandem with GNSS to authenticate a reported position when a GNSS signal is available.

Such a signal is available today, worldwide: STL (Satellite Time and Location). Carried on the Iridium satellites, it is a special purpose signal that is more than 30 dB stronger than GNSS and encrypted for anti-spoof protection. Decoding of this signal is available via a subscription model to users.

Here’s how it would work using a car-sharing example. A group of people subscribe to a car-sharing service that provides X number of cars to serve Y number of people, where X is less than Y. The service optimally schedules people when and where a car will be available. The service provider needs to know the whereabouts of the cars at all times to maximize utilization of the fleet, so every car has a GNSS receiver in it.

But to ensure the authenticity of these reports, they also have a secure localization receiver. This receiver is assigned a unique ID that is authorized to decode the encrypted signal. (Eventually, we expect this receiver and GNSS to converge into one device much the way multi-GNSS receivers operate today).

If a position report does not agree with the authentic localization report, the fleet manager can act to recover the car immediately. Insurance providers who cover secure localization-equipped cars would also give preferential rates as an anti-theft device.

(Image: Pavel Vinnik/Shutterstock.com)

Could PRS do it?

The new Public Regulated Service (PRS) from Galileo is encrypted and could provide a similar level of authentication protection, if made available. However, it is still a weak GNSS signal that can easily be jammed. Of course, any signal can be jammed, even one that is a thousand times stronger than GNSS.

However, given the robust nature of a very strong signal, the managing system that is monitoring the cars — the insurance, toll or car-sharing system, for example — can alarm upon the loss of positioning information. Such alarms on a GNSS-only car would be frequent and often erroneous due to simple fades, yielding so many false alarms that it would render the monitoring system useless. But a loss of both the strong localization signal and GNSS would likely be considered suspicious and result in a valid alarm.

GNSS navigation is truly one of the great advances of the modern era, giving us precise time and location for any place in the world. Its two major weaknesses — that it is easy to jam and spoof — can be overcome by augmenting it with other stronger encrypted signals, such as STL, providing robust jam-resistance and positive authentication.
August 1, 2018
Rambus and Movimento team on personalized security for automotive

Rambus Inc. and Movimento are partnering to deliver secure, personalized over-the-air (OTA) vehicle updates critical to safety and performance in the era of the connected car.

Rambus is a specialist in digital security that provides a secure foundation for a connected world, and Movimento specializes in OTA software lifecycle and data management for the automotive/IoT sectors.

Movimento and Rambus are demonstrating the joint solution at TU-Automotive in Detroit. Visitors can see how the solution works on a live demo using a Dodge RAM truck in Movimento’s booth C67.

Moviemento also took home a TU-Automotive Award for Best Telematics Product/Service for its OTA platform.

The CryptoManager platform adds an important layer of security to the Movimento OTA solution. Vehicle updates provided by the combined Movimento and Rambus solution offers one-time, single-use keys unique to each vehicle, minimizing vulnerabilities and maximizing security.

As part of the collaboration, Movimento’s OTA technology uses the Rambus CryptoManager platform, enabling in-field provisioning of encrypted keys generated for each vehicle and allowing for secure communication between a vehicle and the cloud.

“As cars continue to increase in complexity and connectivity, often depending on more than 100 million lines of code to function, car makers and consumers alike are demanding simple and secure methods to download, authenticate and install vehicle updates,” said Mahbubul Alam, CTO of Movimento. “By partnering with Rambus and integrating the CryptoManager security platform with Movimento’s OTA solutions, we are able to further our strategy of building a best-in-class ecosystem of integrated solutions to enable the software defined car and data analytics.”

Movimento’s tools and technologies are designed to reduce complexity when making software and firmware updates by updating all the ECUs in a car in one go securely. From the chip to the cloud, Movimento builds on more than a decade of experience in automotive industry with the company updating more than 3 million vehicles every year.

“Many current OTA solutions deliver functional updates and security patches for vehicles using the same software encryption key for multiple vehicles, increasing the vulnerability of the update,” said Martin Scott, general manager of the Rambus Cryptography Research Division. “The Rambus CryptoManager solution provides an integrated security platform with flexible implementation from the hardware root-of-trust to the secure firmware which, when combined with Movimento’s OTA technology, enables the next level of integrated chip-to-cloud-to-car security.”

The CryptoManager platform allows for cost reduction by enabling security features already embedded in automotive chipsets and requires no additional security hardware. By utilizing an embedded hardware solution, the CryptoManager platform minimizes the attack surface of the vehicle by providing end point security.

June 8, 2016
Expert Advice: Low-End Jam Resilience May Not Be Desirable

Jan Wendel

By Jan Wendel

At the European Navigation Conference held in Bordeaux, France, April 7–10, a keynote session and ensuing panel discussion addressed the issue of “GNSS Resilience for Terrestrial and Naval Applications.” During the discussion, two questions from the floor drew these responses from panelist Jan Wendel of Airbus Defence & Space GmbH, a leading European aerospace company.

Do you believe that receiver manufacturers will be able to deliver resilient receivers in the future?

JW: In order to achieve resilience, regulatory measures can only provide a mid- to long-term solution. Therefore, resilience needs to be addressed at the receiver level as well.

Considering spoofing, I am not aware of any confirmed spoofing incident. Iran has been claiming to have spoofed a CIA drone, which became for me at least theoretically feasible when I heard the rumor that this drone was equipped with a GPS C/A code receiver. Also, there has been a wrongly configured repeater at the Hannover airport. Nevertheless, spoofing to me does not seem to be a current threat.

However, jamming is clearly a reality nowadays. In my opinion, we should first decide which level of resilience we actually want to achieve for which type of user receiver. If the simple receivers like in smartphones become more and more robust against jamming, the simple jammers available on the Internet will react with an increasing jamming power. This will leave less margin for the receivers used in more critical applications, which we really would like to see functioning permanently.

Therefore, resilience for low-end receivers might not be a good idea; maybe it would be better to see them fail in some scenarios.

Another aspect in the discussion we have had so far is the spreading-code encryption for authentication purposes. Actually, I see spreading-code encryption more as a means to restrict the access of a GNSS signal to authorized users and as an anti-spoofing measure, but not primarily as a means for authentication. Here, we must be aware that the access is not necessarily as restricted as we would like to think.

With directive antennas, blind demodulation techniques and a communication link, it is possible with a slight delay to achieve a position, velocity and time solution at a rover, without being an authorized user of the respective service.

We must understand resilience also in a more global sense, that such a possibility must not be detrimental to the applications assuming a restricted access to specific GNSS services.

Do standards help?

JW: In general, standards are a good thing, as they help in the construction of complex systems by assuring interface compatibility and also minimum performances. However, care needs to be taken when the standards are defined. For example, in the NMEA 0183 protocol, essential information is missing that is required for integration of a GNSS receiver with an inertial navigation system, for example, vertical velocity, full variance-covariance matrices of the receiver’s position and velocity, or raw data like pseudorange, delta ranges and ephemeris to name a few. Clearly, the NMEA protocol was not designed for GNSS/INS integration, and for its intended use the NMEA protocol fits perfectly.

However, for many applications, it is not usable. Being a de-facto standard offered by most receivers, I think it would be beneficial if this protocol would follow more a general-purpose spirit, like most of the proprietary protocols of the different receiver manufacturers do. So with the NMEA protocol lacking relevant information, we are in a situation where for many applications either the receiver manufacturers’ proprietary protocols have to be used — given these protocols offer the required information — or the receiver cannot be used at all. For me, this is an example where a standard is not of great help, also because the process of developing such a standard towards an extended scope takes considerable time, if possible at all.

Jan Wendel is a system engineer at Airbus DS GmbH in Munich, Germany, where he is involved in activities related to satellite navigation, including tracking, integrity and sensor integration algorithms. He received the Dr.-Ing. degree from the University of Karlsruhe, where he is also a private lecturer.

May 29, 2015