Trusted GNSS-Based Time Synchronization for Industry 4

: The protection of satellite-derived timing information is becoming a fundamental re-1 quirement in Industry 4.0 applications, as well as in a growing number of critical infrastructures. 2 All the industrial systems where several nodes or devices communicate and/or coordinate their 3 functionalities by means of a communication network need accurate, reliable and trusted time syn-4 chronization. For instance, the correct operation of automation and control systems, measurement 5 and automatic test systems, power generation, transmission, and distribution typically require a 6 sub-microsecond time accuracy. This paper analyses the main attack vectors and stresses the need 7 for software integrity control at network nodes of Industry 4.0 applications to complement existing 8 security solutions that focus on GNSS RF Spectrum and Precise Time Protocol (PTP), also known 9 as IEEE-1588. A real implementation of a Software Integrity Architecture in accordance with 10 Trusted Computing principles concludes the work together with the presentation of promising 11 results obtained with a ﬂexible and reconﬁgurable testbed for hands-on activities. 12


Introduction 15
The cornerstone of Industry 4.0 [1] are Cyber-Physical Systems (CPS) which are 16 closely connected with computer systems and which can interact and collaborate with 17 other CPS systems [2].These concepts represent the basis of decentralization and   In this scheme, accurate time information is generated by each GNSS satellite and then 57 transmitted by means of properly formatted Radio-Frequency (RF) signals [14,15].A 58 Master Clock node of the network accurately synchronizes its local clock using a GNSS 59 receiver, taking advantage of the signals received from the GNSS satellites visible at its 60 location [16].As illustrated in Figure 1, a distribution network allows to distribute the 61 timing information to all the nodes, achieving an accurate synchronization between the 62 Master Clock and multiple Slave Clocks.The distribution network can take advantage 63 of different protocols and technologies, depending on the application requirements 64 and constraints.Among the others, the Precision Time Protocol (PTP) represents a well-65 known and widely adopted solution for accurate time distribution in a network of 66 clocks organized in a master-slave hierarchy [16,17].Such synchronization protocol, also 67 known as IEEE-1588 standard [18,19], allows for absolute time synchronization in the 68 range of hundreds of nanoseconds through hardware assistance (SyncE) and, potentially, 69 sub-nanosecond accuracy with the White Rabbit extension of PTP (WR-PTP) [20,21].

70
Nevertheless, a conscious adoption of the Industry 4.0 paradigm also requires the 71 introduction of appropriate cybersecurity solutions.In fact, cyberattacks and hacking 72 of factory industrial control systems are dramatically increasing in recent years.Proper 73 mitigation measures against these attacks are needed to avoid the emergence of an internet of insecure industrial things [22].The same statement is also applicable to all 75 the grids and telecommunications networks recognized as critical infrastructures [23,24], 76 especially the upcoming 5G [16,17,25] that is considered as a key enabler for several 77 Industry 4.0 applications.In all these cases, possible synchronization inaccuracies can 78 directly result in a degradation of the quality of service provided by the communication 79 network (e.g., reduced throughput, increased latency and jitter) and, in extreme cases, in 80 a complete disruption of the considered system or application.

81
Two areas in Figure 1  The protection of the timing information over the GNSS RF spectrum and in transit 209 over a PTP network against cyberattacks is not enough to ensure trust and rely on the 210 GNSS precise timing.In fact, even assuming a state-of-the-art distribution network as 211 in Figure 1, including all the previously cited security solutions, such system would  of time coordination, even on limited platforms [46].

260
The protection of the integrity of the SW stack in Figure 2      The identification of a component is made of two steps: the measurement, i.e., a 307 digest, calculated over that component and the storage of such measurement in the TPM, 308 i.e., the accumulation of the measurement via PCR extension operation.
Each PCR can contain one digest value which is the result of one or more PCR 310 extension operations: PCR i+1 = PCR i ||hash(component).For instance, the hash func-311 tion can be sha1, sha256, or sha384.The Infineon TPM used in our prototype [48] 312 implements sha1 and sha256 thus, for the sake of simplicity, we selected sha1.It is 313 not possible to store a value directly in a PCR, but the only way to access a PCR for 314 writing is through the PCR extend operation: this guarantees that all measurements are    Integrity Measurement Architecture (IMA) [50,51] is a security subsystem of the 355 Linux kernel.When enabled, it measures all files that match a given policy (see Ap-356 pendix A.1) that are loaded and possibly executed.All measurement records are kept in 357 memory in the so-called IMA log and an overall integrity checksum is retained using 358 the TPM PCR10.This is an excerpt of an IMA log for the Linux kernel v.4.19 we used: 359 PCR template-hash tpl filedata-hash file-pathname 10 03eb317e687cbd21e360e257b4810f8ac711fb4c ima 9797edf8d0eed36b1cf92547816051c8af4e45ee boot_aggregate 10 1110984f14fc70c87f90053612c3feaa068f66d6 ima 339c9d9d10d1fc25731d6f3d00b80e173e35456c /lib/systemd/systemd 10 bc447ab6e2f476455644dbcf9187c922418f02ba ima 369c4027e9b09131c6971ee963bfd37d41dc251c /lib/arm-linux-gnueabihf/ld-2.28.so 10 e359bd4b3a5b64f125dda645958237a123fe9fe7 ima 9e7916b2b9232f7db4cff863a6588e10253c0285 /etc/ld.so.preload ...  The Attestor sends the nonce to the TCB,     intended to be undetectable with conventional measures (e.g., on ptpd statistics and 511 event logs), and it gradually increases with a consistent sign over the duration of the 512 attack, thus resulting in a frequency drift.In this way, a sufficiently long attack duration 513 can produce arbitrarily large time offsets on the target nodes, potentially with different 514 relative time offsets (i.e., different error magnitude and/or sign).As shown in Figure   On the other hand, the Attack 2 emulates a simpler scenario where we assume that 523 the attacker is only capable to edit the ptpd configuration file (and not its executable

Figure 1 .
Figure 1.Simplified scheme of a GNSS-based synchronization distribution network.

Figure 1
Figure 1 provides a common scheme of a synchronization network, representative

212Figure 2 Figure 2 .
Figure 2 illustrates a possible SW stack running on Master Clock and Slave Clock is of paramount impor-261 tance to avoid that nodes share intentionally modified timing information over any 262 secure version of PTP.Aiming to detect possible intentional changes in the work logic of 263 the Master and/or the Slave node, next section proposes a software integrity architecture 264 based on Trusted Computing principles and customized for embedded devices.

4. Trusted Computing 266 The
Trusted Computing paradigm can be implemented in different ways and as a 267 combination of different approaches and trust decisions to build the Secure Boot and/or 268 Remote Attestation.The following paragraphs present our implementation for the 269 purpose of protecting the integrity of an embedded system operating as a node of a 270 synchronization distribution network.

271 4 . 1 . 1 . 2 . 3 .
Trusted Computing Base 272 Trusted Computing (TC) is used in this paper as per the Trusted Computing Group's 273 (TCG) definition: a set of interoperable technologies to achieve a level of trust in the 274 behaviour of an embedded system.The core element of TC is the hardware Root of 275 Trust called Trusted Platform Module (TPM).A TPM is a tamper resistant piece of 276 cryptographic hardware integrated with the system board that implements primitive 277 cryptographic functions on top of which more complex features can be built in accor-278 dance with TCG specification TPM 2.0 [47].The final objective for the application of TC 279 in this work is to enable nodes to measure and prove cryptographically their integrity, i.e., 280 prove that the software running is the intended one and it has not been tampered with, 281 to the other nodes involved in the synchronization distribution.Integrity measurement 282 is therefore the process the nodes adopt to collect and digest the information about the 283 integrity of their software and configuration for the purpose of being attested/verified.284 The three main hardware Roots of Trust to make the node a Trusted Computing Base 285 (TCB) are: 286 Root of Trust for Measurements (RTM): the Core Root of Trust for Measurements 287 (CRTM) that act as the Trust Anchor; it is commonly implemented by the initial 288 bootloader secure code executed at power up or hardware reset; 289 Root of Trust for Storage (RTS): the TPM that provides (i) a set of Platform Configu-290 ration Registers (PCRs) to securely accumulate the integrity measurements in form 291 of hashes, (ii) a key hierarchy architecture to securely store objects protected via 292 encryption by the TPM on the file system; 293 Root of Trust for Reporting (RTR): the TPM that signs the values of a PCR set 294 using an Attestation Key bound to the Endorsement Key, i.e., a resident key that 295 represents the TPM identity and that guarantees the origin and the integrity of the 296 PCR values shared for the purpose of attestation.

Figure 3 .
Figure 3. Basic Element of a Chain of Trust.

315accumulated.
By building on the fact that the Trust Anchor is trusted by definition and 316 each software component is considered trusted at least to identify the next component, 317 the identification of all components is trusted as well due to the transitive property of 318 trust.The bootstrap process enhanced to build the Chain of Trust, i.e., the capability 319 of each software component to identify and load the next one, is called Authenticated 320 Boot(strap).The Authenticated Boot goes from the CRTM up to the applications in 321 userspace through bootloader and Linux kernel.
is about deciding whether a platform can be considered trusted 324 for an intended purpose or not.It builds upon the Authenticated Boot, can occur (at any 325 meaningful time) during it of after it and implies the cryptographic verification of the 326 loaded software components to identify them and verify that they are the expected ones.327 If the Trust Decision is taken during the bootstrap, the verification is performed by the 328 platform itself (usually using the TPM) over the components loaded until the decision 329 time: based on the result of the verification, the bootstrap process can be stopped.This 330 portion of the Authenticated Boot(strap) is called Secure Boot(strap).If the verification is 331 performed after the bootstrap completion, it is called Remote Attestation, as it requires a 332 remote entity, the Attestor, that performs the verification with the support of the trusted 333 component on the platform, i.e., the TPM.In our prototype we implemented both the 334 Secure Boot and the Remote Attestation.

335 4 . 4 .
Secure Boot 336 The Secure Boot portion can be implemented by means of a combination of the (full) 337 disk encryption with the TPM sealing of the encryption/decryption key to a specific 338 set and configuration of the components loaded and executed before mounting the 339 encrypted partition.Therefore, the availability of the encryption/decryption key is 340 bound to specific values of a set of PCRs containing the accumulated measurements of 341 the loaded components.If such components (and/or their configurations) are different 342 from the expected ones, this is reflected into the PCR values different from those stored 343 along with the encryption/decryption key in a Non-Volatile (NV) storage index.Indeed 344 it is possible to associate a set of PCRs and their values representing a specific configu-345 ration to the disk encryption/decryption key when the data is protected (sealing).The 346 complementary operation is the unsealing when the TPM checks whether the current 347 PCR values meet the values' set stored along with the disk encryption/decryption key.348 If they differ, the TPM does not release the encryption/decryption key (it does the Trust 349 Decision) and, since the encrypted partition cannot be mounted, the bootstrap process 350 gets stopped, thus implementing the Secure Boot.In our prototype we implemented the 351 Secure Boot using a modified version of Cryptsetup [49] that uses a NV storage index to 352 protect the encryption/decryption phase.

353 4 . 5 .
Integrity Measurement Architecture (IMA) 354 360IMA-record = PCR-index || template-hash || tpl || filedata-hash || file-pathname, is the index of the used PCR, with default value equal to 10, i.e., the PCR 363 extended, one-by-one, by template-hash; 364 • tpl is the template name; 365 • template-hash = sha1( filedata-hash length, filedata-hash, ... 366 file-pathname length, file-pathname ); 367 • filedata-hash = sha1( filedata ).368 IMA also includes the function Appraisal that together with the Linux Extended 369 Validation Module (EVM) implements a fine grained Secure Boot process.In our prototype, 370 to implement the Secure Boot we selected the approach based on an encrypted partition 371 and the encryption/decryption key sealed to the TPM and a set of PCR values.

394 2 .
the TCB executes the TPM_Quote, i.e., it signs the PCRs from 0 to 10 and the nonce 395 using the Attestation Key (AK), and prepares the IMA log for delivery,3.the Platform sends back to the Attestor the Quote (i.e., the signature over the values 397 of the PCR from 0 to 10 and the nonce) and the AK certificate, the PCR values, the 398 IMA log, and the list of files measured by the bootloader with their digest; then, 399 4. the Attestor performs all checks to verify the TCB integrity: 400 (a) it verifies the validity of the Quote using the public key embedded in the 401 AK certificate (previously set as trusted), also including the nonce; 402 (b) it verifies that the values of "soft PCRs" calculated from the list of files (and 403 their digest) measured by the bootloader correspond to the values of PCR 0 404 to 8 extended as well by the bootloader; 405

419 5 .Figure 5 .
Figure 5. Picture of the Master clock node (a) and Slave clock node (b).In detail, Figure5(a) shows a picture of a Master node in our testbed, consisting in

Figure 7 .
Figure 7. Obtained results on the testbed during the first attack against the SW integrity (a) and the second attack against the configuration of the PTP daemon (b). 515

7
(a), the first test lasts for approximately one hour and begins with an initial phase in 516 nominal conditions, where all the five nodes are correctly synchronized.Then, the attack 517 actually starts to introduce a time bias at 14:36.In this test, we intentionally introduce a 518 different frequency drift in the two victim nodes (i.e., 1 µs/s on Slave 4 and 0.5 µs/s on 519 Slave 5) during the second part of the test.For this reason, the Slave 4 reaches a time 520 synchronization error larger than 2 ms at the end of the test, while the Slave 5 shows an 521 error larger than 1 ms with respect to all the other Master nodes. 522 524file).In practice, the modified configuration file on each target Slave node introduces a 525 constant time bias with an arbitrarily large magnitude on all the time stamps received 526 from the Master node.Such large bias can result in a time step on the victim clocks during 527 the attack execution, potentially detectable with conventional measures (e.g., on ptpd 528 statistics and event logs).We emulate this attack on our testbed by setting a wrong value 529 for one of the parameters in the ptpd configuration file (i.e., ptpengine:offset_shift).
represent likely targets for potential attacks (i.e., viable attack [26][27][28]h noting that recent scientific literature has extensively investigated attacks 90 to the GNSS RF spectrum (i.e., attack vector 1) and to the PTP protocol and packets 91 over the network (i.e., 2.a).Proper countermeasures against them are already available 92 (e.g., refer to[26][27][28]and references therein).For this reason, following sections will 93 summarize these specific attack vectors, while their experimental assessment is out of 94 the scope for this paper.95Onthe other hand, to the best of the authors' knowledge, previous works have not 96 widely covered the attacks to the PTP SW integrity within nodes (i.e., 2.b).This category 97 of attacks is gaining special attention in both scientific and industrial communities, 98 where the investigation of possible cybersecurity solutions is an active research topic, 99 stressing the need for software integrity control at network nodes.For these reasons, 100 we recognize this category of attacks and related solutions as especially relevant and 101 challenging for Industry 4.0 applications and, thus, worth of further investigation.102 Motivated by this background, the paper has the following objectives: 103 • an analysis of attack vectors for GNSS-based synchronization distribution networks, 104 with a special attention to attacks not widely covered in prior work (i.e., 2.b); 105 • the proposition of a novel solution for PTP nodes augmented with Trusted Computing 207 3.2.Attacks Against the SW Integrity and Configuration of the Nodes 208 c) it calculates the digest of the AK certificate and the value of a "soft PCR" 412integrity status can be: trusted if all files in the IMA log are found in 413 whitelists; unknown if at least one file in the IMA log is not found in whitelists 414 but no file is found in blacklists; and untrusted if at least one file in the 415 IMA log is found in blacklists or if any of the checks from (a) to (d) fails.4165.Finally, the Attestor closes the TLS channel and takes the appropriate action(s).417Whichare the appropriate action(s) depends on the specific Industry 4.0 application and 418 they are subject to further research.