The emergence of a multi-GNSS world will inevitably require the civil GNSS user community to address the issue of signal authentication: confirming that a pretended identity of a user or transmitted information is, in fact, real and correct.
This two-part column focuses on the concepts and methods for achieving authentication in GNSS operations. In the July/August issue, the column began by introducing some of the cryptographic concepts, terminology, and techniques used to develop and implement authentication methods in navigation systems in general.
The emergence of a multi-GNSS world will inevitably require the civil GNSS user community to address the issue of signal authentication: confirming that a pretended identity of a user or transmitted information is, in fact, real and correct.
This two-part column focuses on the concepts and methods for achieving authentication in GNSS operations. In the July/August issue, the column began by introducing some of the cryptographic concepts, terminology, and techniques used to develop and implement authentication methods in navigation systems in general.
This second and final installment will discuss the possibilities of navigation message authentication, and examine public and private spreading code authentication as well as navigation message encryption and spreading code encryption. We will also draw some conclusions about these concepts’ application in GNSS.
Navigation Message Authentication (NMA)
NMA denotes the authentication of satellite signals by means of digitally signing the modulated navigation data. For each satellite, valid signing/validation-key pairs (ks, kv) are generated. The signing key ks is kept secret and is only known by the ground segment and the respective satellite. The validation key kv is made public in an authenticable manner, for example, by means of certificates in a public key infrastructure.
The navigation message consists of one or several data blocks DN, containing the orbit and clock parameters, and of one or several data blocks containing the digitally signature DS. The digital signature DS is computed, as described in Part 1 of this article, e.g., by hashing the data blocks DN and subsequently encrypting the hash value under the signing key ks.
The recipient receives the data blocks DN and the signature blocks DS via the modulated data bits on the ranging signal. After receiving a complete message, the recipient can authenticate it by means of the validation function, for example by comparing the hash value of the data blocks DN with the outcome of the decrypted signature under the publicly known validation key kv.
This method demands that the validation key kv is known to the receiver in an authentic manner. This can be achieved by means of an interface to the receiver with which the user can input the validation key. The validation key is published on the Internet merged in a certificate signed by a trustworthy entity.
As shown in Figure 1, however, the key distribution scheme for the upcoming Galileo system is planned in a different way. Rather than publishing on the Internet, the validation key is packed in a certificate and transferred via the modulated data on the ranging signal itself. The receiver proofs the validity of the validation key over a validation chain up to the root certificate. Again, this root certificate has to be known to the receiver in an authentic manner. Thus, the same arrangements have to be implemented as previously described.
Compared to the first approach — using the Internet and a direct interface to the receiver — the data overhead is notably increased. Furthermore, in this proposed Galileo architecture, the authentication method is not available until all certificates are received and validated. In case of direct key input to the receiver, the question of acquisition time does not arise.
(For the rest of this story, please download the complete article using the link above.)
