Add work on the OSNMA description

_posts/2024-07-11-osnma.md

@@ -121,14 +121,49 @@ If the result of all these steps is successful the user can consider the navigat
   {: style="text-align: center;"}
 
 
-## Implementation of cryptographic functions.
+OSNMA defines different Authentication Data & Key Delay (ADKD) types. Each type authenticates different parts of the I/NAV data transmitted by satellites which is used to generate the associated tag. A tag is defined as a truncated Message Authentication Code (MAC). The currently defined types are:
 
-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. 
+- **Tag ADKD 0 - Galileo I/NAV Ephemeris, Clock and Status:**  The tag authenticates I/NAV data transmitted in the previous I/NAV sub-frame. The data authenticated are Word Types 1 to 5, retrieved from either E1-B or E5b-I, including: IODnav, Ephemeris, SISA(E1,E5b), SVID, Clock correction, Ionospheric correction, BGDs, HS and DVS flags.
+
+- **Tag ADKD 4 - Galileo I/NAV Timing Parameters:** The tag authenticates the I/NAV data from the Word Type 6 transmitted one sub-frame earlier and the Word Type 10, transmitted one or two subframes earlier (retrieved from E1-B only). The data authenticated includes: GST-UTC conversion parameters (Word Type 6) and GST-GPS conversion parameters (Word Type 10). 
+
+- **Tag ADKD 12 - Slow MAC - Galileo I/NAV Ephemeris, Clock and Status:** The tag is generated as per ADKD=0 definition, but using a key that is published with an additional 10 sub-frames delay (5 minutes). 
+
+The possible sequences of transmitted tags (either for self-authentication or cross-authentication of satellite data) are predefined in a look-up table. In those sequences, some slots are fixed, and others are flexible (not defined in the look-up table) and its content definition (which is found in the Tag-Info data) needs to be authenticated through the corresponding TESLA key.
+
+The truncated Message Authentication Codes (MACs), or tags, with specific information data associated (Tag-Info), and the TESLA key are conveyed in the MACK messages described above. Looking into their structure in more detail, there is a MACK header defined as:
+
+  ![MACK header]({{ "/assets/images/MACK_header.png" | relative_url }}){:width="200px"}{: .align-center .invert-colors}
+  *MACK message header (from OSNMA SIS-ICD [^OSNMA-ICD]).*
+  {: style="text-align: center;"}
+
+The $$ \text{Tag}_{0} $$ field contains a tag obtained by truncating a MAC of type “ADKD=0” for the satellite transmitting the OSNMA data, and it is always the first tag of the MACK message. THE MACSEQ field allows the receiver to authenticate the Tag-Info field for the tags whose ADKD type is identified as flexible, and the Data Cut-Off Point (COP) indicates the maximum time lag between the tag and the navigation data it authenticates.
+
+The next field in the MACK message is Tags&Info, defined as a sequence of tags and their corresponding Tag-Info data:
+
+  ![MACK Tags&Info]({{ "/assets/images/MACK_tags_info.png" | relative_url }}){:width="400px"}{: .align-center .invert-colors}
+  *MACK message's Tags&Info field (from OSNMA SIS-ICD [^OSNMA-ICD]).*
+  {: style="text-align: center;"}
+
+The tags are obtained by generating a certain MAC, following the specific information within the Tag-Info field, and then truncating it (starting from the MSB) to the length defined by the Tag Size field within the DSM-KROOT of the chain in force.
+
+The OSNMA-equipped receiver must store these sequences of tags. In the next sub-frame (or ten sub-frames later for ADKD 12), it will receive the TESLA key that allows it to compute the MAC and, consequently, the tags. The receiver can then compare the computed tags to the received sequence. If they match, the received data can be declared authenticated.
+
+## Implementation of cryptographic functions
+
+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. In the testing phase, only SHA-256, HMAC-SHA-256, and ECDSA P-256 are used, but the others could be used in the future.
 
 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:
 
-- [OpenSSL](https://www.openssl.org/)
-- [GnuTLS](https://www.gnutls.org/)
+- [OpenSSL](https://www.openssl.org/) is a robust, commercial-grade, full-featured toolkit for general-purpose cryptography and secure communication. Versions 1.x were published under a dual-license scheme that was incompatible with the GPLv3.0 license, preventing the library from being a mandatory dependency for GNSS-SDR in most GNU/Linux distributions. OpenSSL 1.1.1, relesed on 11 Sep 2018, already implemented the required OSNMA functions. The licensing issue was resolved in OpenSSL version 3.0.0, which transitioned to the Apache License 2.0, fully compatible with GPLv3.0. Released on September 7th, 2021, OpenSSL 3.0.0 and its subsequent updates support the implementation of all cryptographic functions required by the OSNMA service and have been incorporated into major GNU/Linux distributions released since 2022. For instance, in Debian/Ubuntu-based distributions it can be installed as ```sudo apt install libssl-dev```.
+- [GnuTLS](https://www.gnutls.org/) is used as a fallback if OpenSSL is not found in the host system when building GNSS-SDR. This Transport Layer Security library, published under the GNU Lesser General Public License (LGPL), is available even in older GNU/Linux distributions. However, some operating systems may omit the optional (but necessary) SSL module. For instance, in Debian/Ubuntu-based distributions it can be installed as ```sudo apt install libgnutls-openssl-dev```. In is known to implement all the required OSNMA functions since version 3.6.13, released on 24 Apr 2020.
+
+## Other OSNMA implementations
+
+- **[OSNMAlib](https://github.com/Algafix/OSNMA)** is an open-source Python library that can be used for research purposes or be integrated into existing receivers (among them, GNSS-SDR) and applications to incorporate navigation message authentication to the positioning process.
+
+- **[galileo-osnma](https://github.com/daniestevez/galileo-osnma)** is a Rust implementation of the OSNMA protocol that can be used in some embedded microcontrollers.
+
 
 ## Conclusions
 The integration of OSNMA within GNSS-SDR represents a significant step forward in enhancing GNSS receiver security.