# Trusted GNSS-Based Time Synchronization for Industry 4.0 Applications
## 3 Time Distribution Network Attack Vector
### Attacks against the SW Integrity and Configuration of the Nodes  
The protection of the timing information over the GNSS RF spectrum and in transit over a PTP network against cyberattacks is not enough to ensure trust and rely on the GNSS precise timing. In fact, even assuming a state-of-the-art distribution network as in Figure 1, including all the previously cited security solutions, such a system would still be vulnerable to potential attacks against the software integrity of Master and/or Slave nodes. Specific attacks targeting the integrity of the SW stack running within those nodes must also be considered to avoid nodes that exchange incorrect synchronization information over secure protocols. Figure 2 illustrates a possible SW stack running on Master Clock and Slave Clock nodes. We adopt the simplified scheme in Figure 2 as a study case, intended to be as generally as possible and representative of the typical SW modules installed and configured on real PTP nodes, but without the ambition to cover all the possible SW configurations and different hardware components (e.g., Network Interface Card with or without PTP hardware timestamping, internal clock steering done via SW or with a dedicated FPGA, etc.). We propose two possible configurations for the Master node on the left side and on the central part of Figure 2, respectively. Both these configurations include a GNSS module capable to receive the RF signals from one or multiple satellite constellations (e.g., GPS, Galileo, GLONASS, and/or BeiDou) in order to estimate Position, Velocity, and Time (PVT) information. The GNSS receiver typically provides two outputs:  
1. a textual interface over a serial communication protocol, providing the PVT data coded as \"sentences\" according to the National Marine Electronics Association (NMEA) 0183 standard [39], and
2. the 1 Pulse-Per-Second (1 PPS), that is a high precision analog signal having leading pulse edges synchronous with the beginning of each second of the time scale. Different SW tools and/or daemons can accept as inputs the NMEA and 1 PPS, taking advantage of the Linux kernel support to make them visible as devices [40]. In the configuration #1, these devices are a serial port for NMEA (/dev/serial0) and the Linux Pulse Per Second Application Programming Interface (PPSAPI) for 1 PPS (/dev/pps0) [40]. A service daemon capable to parse the GNSS data (i.e., gpsd [41]) uses both of them as inputs. We also shared such inputs to ntpd, a daemon implementing the Network Time Protocol (NTP) version 4 [42], by means of two shared memory segments (i.e., 127.127.28.0 and 127.127.28.2) properly configured using the Shared Memory Driver of ntpd [43]. In this way, ntpd is capable to correctly discipline the internal clock of the Master node, ensuring its accurate synchronization with respect to the GNSS time scale. The configuration #2 represents a simplified alternative without gpsd. In this case, we directly provide the NMEA and 1 PPS outputs of the GNSS receiver to ntpd by means of two symbolic links to the actual devices (i.e., /dev/gps0 and /dev/gpsps0, respectively). It is worth noting that ntpd can use these symbolic links as two separate inputs, taking advantage of two dedicated drivers (i.e., the Generic NMEA GPS Receiver [44] and the PPS Clock Discipline [45]) or as a single NMEA stream directly disciplined by the 1 PPS (i.e., by properly setting the fudge flag1 of the Generic NMEA driver to enable the PPS signal processing [44]). The second option is preferable in order to simplify the configuration of ntpd, thus we will use it in the following discussion. Once ntpd has correctly synchronized the internal clock of the Master node, both the configurations #1 and #2 adopt the PTP daemon (i.e., ptpd [46]) to distribute the time synchronization over the network. In accordance to PTP working principles, ptpd can accurately synchronize multiple Slave nodes to the internal clock of the Master node.