If you wish to contribute or participate in the discussions about articles you are invited to contact the Editor
GNSS Authentication and encryption: Difference between revisions
Gema.Cueto (talk | contribs) No edit summary |
Gema.Cueto (talk | contribs) No edit summary |
||
Line 11: | Line 11: | ||
* Communications may be encrypted (e.g. encoded) to keep them secret and make them unreadable to a third party. | * Communications may be encrypted (e.g. encoded) to keep them secret and make them unreadable to a third party. | ||
* Authentication is an additional mechanism in which communications are digitally signed to verify its authenticity. | * Authentication is an additional mechanism in which communications are digitally signed to verify its authenticity. | ||
* Authentication and encryption mechanisms are one of the countermeasures which can help to mitigate spoofing attacks. | |||
==Encryption== | |||
As it was mentioned before, the idea behind encryption is to make GNSS signals unreadable to non-allowed users. The encryption codes and algorithms used are secret and without them it is impossible to spoof. Moreover, receivers compatible with this solution must include the classified algorithms, have the relevant key repository and be certified for such use. | |||
The encryption can be symmetric (sender and receiver both hold the same secret information) or asymmetric (different information held by the two parties). | |||
Current examples of encrypted GNSS signals are GPS P(Y) code for military use, [[Galileo Public Regulated Service (PRS) | Galileo PRS]] or [[Galileo High Accuracy Service (HAS) | Galileo HAS]] (this latter will include providing an additional encrypted navigation signal in a E6 band). | |||
==Authentication== | |||
In GNSS, authentication can be defined as the capability of a GNSS receiver to verify the authenticity of the GNSS information and of the entity transmitting it, to ensure that it comes from a trusted source. Authentication is an intrinsic GNSS capability remaining internal to the GNSS receiver. | In GNSS, authentication can be defined as the capability of a GNSS receiver to verify the authenticity of the GNSS information and of the entity transmitting it, to ensure that it comes from a trusted source. Authentication is an intrinsic GNSS capability remaining internal to the GNSS receiver. |
Revision as of 08:11, 16 February 2021
Fundamentals | |
---|---|
Title | GNSS Authentication and encryption |
Edited by | GMV |
Level | Basic |
Year of Publication | 2021 |
The basic idea behind authentication and encryption is to ensure that a message is identical to the one transmitted at its origin and that it was generated by a trusted source. Encryption and authentication refer to two interrelated mechanisms to protect communications:
- Communications may be encrypted (e.g. encoded) to keep them secret and make them unreadable to a third party.
- Authentication is an additional mechanism in which communications are digitally signed to verify its authenticity.
- Authentication and encryption mechanisms are one of the countermeasures which can help to mitigate spoofing attacks.
Encryption
As it was mentioned before, the idea behind encryption is to make GNSS signals unreadable to non-allowed users. The encryption codes and algorithms used are secret and without them it is impossible to spoof. Moreover, receivers compatible with this solution must include the classified algorithms, have the relevant key repository and be certified for such use.
The encryption can be symmetric (sender and receiver both hold the same secret information) or asymmetric (different information held by the two parties).
Current examples of encrypted GNSS signals are GPS P(Y) code for military use, Galileo PRS or Galileo HAS (this latter will include providing an additional encrypted navigation signal in a E6 band).
Authentication
In GNSS, authentication can be defined as the capability of a GNSS receiver to verify the authenticity of the GNSS information and of the entity transmitting it, to ensure that it comes from a trusted source. Authentication is an intrinsic GNSS capability remaining internal to the GNSS receiver.
Different authentication techniques may be considered (unpredictable features at subcarrier or carrier level, as variable pulse shaping, frequency hopping, etc.), however the most promising ones are related to the authentication of the navigation messages.
Most Navigation Message Authentication (NMA) techniques are based on the Timed Efficient Stream Loss-Tolerant Authentication (TESLA) protocol [1]. One of the greatest advantages of this protocol is that it requires low bandwidth to transmit the authentication information, together with a tolerance to data loss in case a message is lost. Some variations and modifications have been proposed exploiting one or more signal components providing, in general, a high level of robustness against simplistic and intermediate spoofing attacks. This category of spoofing includes all the cases where the spoofer is able to generate asynchronous or synchronous counterfeit signals, but not to predict and/or a-priori generate valid NMA data. In fact, from a spoofer perspective, the cryptographically-protected data are not predictable a-priori and cannot be pre-computed by the spoofer. In this sense, a spoofer unable to generate valid cryptographic data can be easily detected by a receiver that implements the NMA algorithm.
Up until now, the main operational GNSS systems which have considered including authentication capabilities are GPS and Galileo. In the case of GPS, a Chips-Message Robust Authentication (Chimera) approach, which is a hybrid NMA and spreading code authentication technique has been proposed for use within the new GPS L1C signal. The NMA portion of this scheme is based on a well-established standard, the asymmetric elliptic curve digital signature algorithm (ECDSA) P-224, which simplifies the integration of the scheme into existing GNSS receivers.
In the case of Galileo OS-NMA; this feature consists in digitally signing the Open Service Navigation message in the E1 band, making use of forty reserved bits in the Galileo E1B data message and the TESTA protocol, thus keeping the rest of the navigation message unencrypted.
Notes
References
- ^ I. Fernández-Hernández, V. Rijmen, G. Seco-Granados, J. Simon, I. Rodríguez, and J. David Calle, “A Navi-gation Message Authentication Proposal for the Galileo Open Service,” Navigation, Journal of The Institute of Navigation, vol. 63, no. 1, pp. 85-102