Add work on the OSNMA description

_posts/2024-07-11-osnma.md

@@ -17,6 +17,11 @@ GNSS signal spoofing has become a frequent and concerning issue, particularly in
 
 Galileo, the European GNSS, is currently testing its Open Service Navigation Message Authentication (OSNMA) service. OSNMA is designed to provide a secure, spoof-proof communication channel between satellites and receivers. This service transmits authentication data within the Galileo E1 I/NAV messages, alongside the navigation data used by receivers to compute PVT solutions. By incorporating OSNMA, the resilience of GNSS receivers to spoofing attacks is significantly enhanced, since they can detect spoofed signals and act upon that event.
 
+OSNMA makes use of different keys from a single one-way chain shared by the Galileo satellites through a Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol.[^Perrig03]
+
+The main idea of the TESLA protocol is that the sender appends a message authentication code (MAC) to each data packet, computed using a key $$ K $$ known only to the sender. The receiver buffers the received packet without being able to authenticate it immediately. Shortly afterward, the sender discloses $$ K $$, allowing the receiver to authenticate the packet.
+{: .notice--info}
+
 The OSNMA data is broadcast across multiple Galileo satellites, requiring the receiver to combine the received data effectively to implement the service. Consequently, the proposed software architecture includes a processing block that asynchronously collects the OSNMA data received from all available Galileo E1 OS processing channels. This block then combines and processes the OSNMA data, and asynchronously transmits the list of authenticated satellites to the PVT computation block, which, based on user configuration, either warns the user or excludes unauthenticated satellites from the PVT solution computation.
 
 ![OSNMA architecture]({{ "/assets/images/OSNMA-arch.png" | relative_url }}){:width="600px"}{: .align-center .invert-colors}
@@ -42,44 +47,57 @@ The strict mode (that is, PVT fixes are computed exclusively from authenticated
 GNSS-SDR.osnma_mode=strict
 ```
 
+Check out the page about [OSNMA configuration in GNSS-SDR]({{ "/docs/sp-blocks/global-parameters/#open-service-navigation-message-authentication-osnma" | relative_url }}) for more information.
+
 ## Extraction of OSNMA data from signals in space
 
-According to the Signal-In-Space Interface Control Document [^OSNMA-ICD], the Galileo OSNMA protocol data are transmitted within the odd pages of the nominal E1-B I/NAV message. The bits are placed in previously reserved positions:
+According to the Signal-In-Space Interface Control Document,[^OSNMA-ICD] the Galileo OSNMA protocol data are transmitted within the odd pages of the nominal E1-B I/NAV message. The bits are placed in previously reserved positions:
 
 ![OSNMA data]({{ "/assets/images/OSNMA_data.png" | relative_url }}){:width="500px"}{: .align-center .invert-colors}
-*E1-B I/NAV Nominal Page with bits allocation (from OSNMA SIS-ICD[^OSNMA-ICD])*
+*E1-B I/NAV Nominal Page with bits allocation (from OSNMA SIS-ICD[^OSNMA-ICD]).*
 {: style="text-align: center;"}
 
 OSNMA data are distributed only by a subset of the Galileo satellites. If a satellite is not part of the above mentioned subset, the I/NAV OSNMA message will contain a 40-bit sequence of zeros. 
 
 The OSNMA field has the following structure: 
 
-![OSNMA message]({{ "/assets/images/OSNMA_msg.png" | relative_url }}){:width="300px"}{: .align-center .invert-colors}
-*OSNMA data message (from OSNMA SIS-ICD [^OSNMA-ICD])*
+![OSNMA message]({{ "/assets/images/OSNMA_msg.png" | relative_url }}){:width="200px"}{: .align-center .invert-colors}
+*OSNMA data message (from OSNMA SIS-ICD [^OSNMA-ICD]).*
 {: style="text-align: center;"}
 
 - **The HKROOT (header and root key) section** is an 8-bit portion of a 120 bits long message, which is transmitted once every 30 seconds, *i.e.* within each E1B I/NAV sub-frame. The HKROOT message begins always with an 8-bit NMA Header field, followed by a 112-bit Digital Signature Message (DSM) field, consisting of a DSM Header, followed by a DSM block:
 
   ![HKROOT message]({{ "/assets/images/HKROOT.png" | relative_url }}){:width="600px"}{: .align-center .invert-colors}
-  *HKROOT Message (from OSNMA SIS-ICD [^OSNMA-ICD])*
+  *HKROOT Message (from OSNMA SIS-ICD [^OSNMA-ICD]).*
   {: style="text-align: center;"}
 
   Several DSM blocks, transmitted through successive subframes, form a complete DSM. Different satellites can transmit different blocks of the same DSM at a given sub-frame.
 
   There are two different types of DSM:
     - DSM-PKR, providing the Public Key for the verification of the root key of the TESLA chain. The Public Key in force, together with its ID and signature algorithm, is provided in the DSM-PKR message every 6 hours (starting at 00:00 GST, 06:00 GST, 12:00 GST and 18:00 GST) for a period of 30 minutes. If the Public Key has not been provided by the user in the `GNSS-SDR.osnma_public_key` configuration parameter, the receiver will retrieve it from the signals in space.
-    - DSM-KROOT, providing a digitally signed root key for a TESLA chain. 
+    - DSM-KROOT, providing a digitally signed root key for the TESLA chain in force, or the one of the next chain, and the means to authenticate those keys using the Public Key in force.
 
-- **The MACK (message authentication code and key) section** is a 32-bit portion of a 480 bits long message, which is transmitted once every 30 seconds, *i.e.* within each E1-B I/NAV sub-frame. Each MACK message contains several truncated Message Authentication Codes (MACs), or tags, with specific information data associated (Tag-Info), and a Timed Efficient Stream Loss-Tolerant Authentication (TESLA) key.
+- **The MACK (message authentication code and key) section** is a 32-bit portion of a 480 bits long message, which is transmitted once every 30 seconds, *i.e.* within each E1-B I/NAV sub-frame. Each MACK message contains several truncated Message Authentication Codes (MACs), or tags, with specific information data associated (Tag-Info), and a TESLA key.
 
-  ![MACK message]({{ "/assets/images/MACK.png" | relative_url }}){:width="400px"}{: .align-center .invert-colors}
-  *MACK Message (from OSNMA SIS-ICD [^OSNMA-ICD])*
+  ![MACK message]({{ "/assets/images/MACK.png" | relative_url }}){:width="300px"}{: .align-center .invert-colors}
+  *MACK Message (from OSNMA SIS-ICD [^OSNMA-ICD]).*
   {: style="text-align: center;"}
 
 Therefore, a 120-bit HKROOT message and a 480-bit MACK message are transmitted every 30 seconds. Both HKROOT and MACK messages are split into 15 portions of equal size (8 or 32 bits) and transmitted within each 40-bit OSNMA data message.
 
+In OSNMA, the MAC algorithm used to authenticate the *plain text* navigation message can be either HMAC-SHA-256[^FIPS-198-1] or CMAC-AES[^ISO-9797-1], the former being used in the Testing phase. The TESLA keys belong to a chain that begins with a random seed key $$ K_N $$, known only to the sender (in this case, the OSNMA provider), and ends with a root key $$ K_0 $$ that is public and certified through the DSM-KROOT messages. A TESLA key $$ K_N $$ can be verified against the root key $$ K_0 $$ by computing $$ F^N(K_N) $$ and comparing the result with $$ K_0 $$. In OSNMA, the function $$ F(\cdot) $$ is defined in the ICD[^OSNMA-ICD]. 
+
+  ![TESLA key chain]({{ "/assets/images/TESLA_chain.png" | relative_url }}){:width="600px"}{: .align-center .invert-colors}
+  *TESLA key chain, where $$ K_{n} = F(K_{n+1}) $$.*
+  {: style="text-align: center;"}
+
+The TESLA root key $$ K_0 $$ retrieved from the DSM-KROOT message is verified using an Elliptic Curve Digital Signature Algorithm (ECDSA)[^FIPS-186-5], by signing the data with a private key known only to the OSNMA provider and verifying it at the receiver with a public cryptographic key. That ECDSA Public Key can be either retrieved from the [European GNSS Service Centre website](https://www.gsc-europa.eu/) and passed to GNSS-SDR via the `GNSS-SDR.osnma_public_key` configuration parameter, or from the Signal in Space broadcasted by Galileo satellites. The Public Key in force, together with its ID and signature algorithm, is provided in the DSM-PKR message every 6 hours for a period of 30 minutes, mixed with other DSM-KROOT messages. The receiver must authenticate this reception against a [Merkle Tree](https://en.wikipedia.org/wiki/Merkle_tree) root $$ x_{4, 0} $$ (see figure below), using the same hashing algorithm that was employed for tree generation, currently SHA-256[^FIPS-180-4]. In the future, the system may adopt SHA3-256[^FIPS-202].
 
+  ![OSNMA Merkle Tree]({{ "/assets/images/MerkleTree.png" | relative_url }}){:width="600px"}{: .align-center .invert-colors}
+  *OSNMA Merkle Tree (from OSNMA SIS-ICD [^OSNMA-ICD]).*
+  {: style="text-align: center;"}
 
+Some nodes of the Merkle Tree (among them, the root node $$ x_{4, 0} $$) can be retrieved from the [European GNSS Service Centre website](https://www.gsc-europa.eu/) and passed to GNSS-SDR via the `GNSS-SDR.osnma_merkletree` configuration parameter. Note that a renewal of the Merkle tree is expected to take place very rarely, typically after more than 10 years, so GNSS-SDR already comes with pre-loaded values that are used in the case that `GNSS-SDR.osnma_merkletree` is not defined.
 
 ## Processing of the authentication material 
 
@@ -98,14 +116,14 @@ From a receiver perspective, the process of the OSNMA data can be described at a
 
 If the result of all these steps is successful the user can consider the navigation data as authentic. [^OSNMA-RG]
 
-  ![OSNMA Processing]({{ "/assets/images/OSNMA_processing.png" | relative_url }}){:width="500px"}{: .align-center .invert-colors}
-  *OSNMA processing logic (from the OSNMA Receiver Guidelines [^OSNMA-RG])*
+  ![OSNMA Processing]({{ "/assets/images/OSNMA_processing.png" | relative_url }}){:width="500px"}{: .align-center}
+  *OSNMA processing logic (from the OSNMA Receiver Guidelines [^OSNMA-RG]).*
   {: style="text-align: center;"}
 
 
 ## Implementation of cryptographic functions.
 
-The OSNMA protocol requires the availability of two secure hash standards (SHA-256[^FIPS-180-4] and SHA3-256[^FIPS-202]), two message authentication code functions (HMAC-SHA-256[^FIPS-198-1] and CMAC-AES[^ISO-9797-1]) for tag verigication, and two Elliptic Curve Digital Signature Algorithms[^FIPS-186-5] (ECDSA P-256 and ECDSA P-521) for the verification of the TESLA root key. 
+The OSNMA protocol requires the availability of two secure hash standards (SHA-256 and SHA3-256), two message authentication code functions (HMAC-SHA-256 and CMAC-AES) for tag verigication, and two Elliptic Curve Digital Signature Algorithms (ECDSA P-256 and ECDSA P-521) for the verification of the TESLA root key. 
 
 Implementing cryptographic functions in C++ from scratch is often unnecessary and inefficient. Instead, leveraging well-known, reliable, and actively maintained open-source libraries ensures robust and secure implementations. These libraries undergo continuous testing and updates, benefiting from scrutiny by a vast user base. In the GNSS-SDR implementation, the objective was to enable the OSNMA service across the broadest possible range of hardware and software environments, covering diverse setups such as embedded SoC/FPGA-based platforms, a Raspberry Pi 5, an x86-64-based personal computer, or even a macOS-based Apple silicon processor. The required open-source dependency options, which are transparent to the user and automatically picked up by the build configuration system upon availability, are:
 
@@ -130,4 +148,6 @@ The integration of OSNMA within GNSS-SDR represents a significant step forward i
 
 [^FIPS-186-5]: National Institute of Standards and Technology, [FIPS PUB 186-4 - Digital Signature Standard (DSS)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf), U.S. Department of Commerce, February 2023.
 
-[^OSNMA-RG]: [Galileo Open Service Navigation Message Authentication (OSNMA) Receiver Guidelines](https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OSNMA_Receiver_Guidelines_v1.3.pdf), Issue 1.3, January 2024.
+[^OSNMA-RG]: [Galileo Open Service Navigation Message Authentication (OSNMA) Receiver Guidelines](https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OSNMA_Receiver_Guidelines_v1.3.pdf), Issue 1.3, January 2024.
+
+[^Perrig03]: A. Perrig, J. D. Tygar, "TESLA broadcast authentication," Secure Broadcast Communication: In Wired and Wireless Networks, Springer (Kluwer), pp. 29–53, 2003.

_sp-blocks/01-global-parameters.md

@@ -96,7 +96,7 @@ GNSS-SDR.observable_interval_ms=10
 
 The Galileo OSNMA service is enabled by default if the configuration file defines `1B` (that is, Galileo E1 OS) channels. 
 
-Users must register and log in on the [EUSPA website](https://www.gsc-europa.eu/), and download the OSNMA public key ("GSC Products > OSNMA_PublicKey", the file with `.crt` format) and the OSNMA Merkle Tree root file ("GSC Products > OSNMA_MerkleTree", in `.xml` format), and set the corresponding options in the GNSS-SDR configuration file:
+Users must register and log in on the [European GNSS Service Centre website](https://www.gsc-europa.eu/), and download the OSNMA public key ("GSC Products > OSNMA_PublicKey", the file with `.crt` format) and the OSNMA Merkle Tree root file ("GSC Products > OSNMA_MerkleTree", in `.xml` format), and set the corresponding options in the GNSS-SDR configuration file:
 
 |----------
 | **Parameter**  | **Description**                                   | **Required** |