First Results of a Formal Analysis of the Network Time Security Specification

Abstract

This paper presents a first formal analysis of parts of a draft version of the Network Time Security specification. It presents the protocol model on which we based our analysis, discusses the decision for using the model checker ProVerif and describes how it is applied to analyze the protocol model. The analysis uncovers two possible attacks on the protocol. We present those attacks and show measures that can be taken in order to mitigate them and that have meanwhile been incorporated in the current draft specification.

A ProVerif Source Code

In this appendix, we present some of the relevant ProVerif source code used for the preparation of this paper. There have been different code versions involved in the analysis:

• Code version c030ut: It models protocol version 0.3.0 but has no dedicated type for hostnames.

• Code version c030: It models protocol version 0.3.0 and does have a dedicated hostname type.

• Code version c031: It models protocol version 0.3.1.

• Code version c032: It models protocol version 0.3.2.

All of the code below is taken from code version c030, which formed the basis of the analysis. Presenting the other versions in full would take up a lot of space, whereas presenting only the differences is difficult. This is because although the changes between the different code versions are minor, they still include numerous lines that are spread far apart. Some comment lines and structuring have been left out for the presentation.

For any reader who is interested in access to the complete code (all code versions, ready for use with ProVerif), it is available under https://www8.cs.fau.de/staff/milius/ProVerif-NTS.rar.

1.1 A.1 Cryptographic Primitives

The first lines of the ProVerif source code form the cryptographic primitives that are needed.

1.2 A.2 Global Variables and Constants

Next we have the declarations of channels and other global variables and constants.

1.3 A.3 Events

The declarations of ProVerif “events” follow that are used for better traceability of what is happening in what order.

1.4 A.4 The Trusted Authority Process

The code then moves on to the processes by which the participants are modeled. We first present the process that models the trusted authority. Its only purpose is to generate and distribute certificates for server and client type participants.

1.5 A.5 The Server Side Processes

Inner Server Processes. Next are those processes that make up the model of the server. The first process represents the server module which deals with the certification message exchange.

The next process involves the server module whose purpose it is to execute the cookie message exchange as well as the required calculations.

Then the server module follows that takes care of the time synchronization message exchange.

Outer Server Process. We then see the “outer” server process whose purpose is simply to execute iterations of all the “inner” processes (the modules listed above in Appendix A.5).

1.6 A.6 The Client Side Processes

Inner Client Process. Moving on to the client side processes, there is first the “inner” process which takes care of the time synchronization message exchange, including the necessary checks on the MAC.

Outer Client Process. The “outer” client side process follows, which performs the initial message exchanges (server certification and cookie exchange) and then executes instantiations of the inner process.

Note that the first else-branch includes all the code below it. Note also the dedicated listener process given by

which is started when the client accepts a cookie and does not really represent client behavior according to the protocol, but only listens for the cookie on an open channel. This enables us to check for the loss of a cookie by querying whether the event cookieCompromised() is ever executed at all (see Appendix A.8).

1.7 A.7 The Environment Process

Here, we present the global ProVerif process which takes care of instantiating all participants.

1.8 A.8 ProVerif Queries

Now we present the ProVerif queries. We first consider those queries that concern the cookie exchange.

Sanity – Cookie Exchange. This query makes sure that there is some cookie $x$ which is accepted by the honest client $A$ as coming from the honest server $B$, i. e. the cookie exchange can be completed successfully.

This query holds for all four code versions.

Weak Authenticity – Cookie. This query ensures that if the honest client $A$ accepts a cookie $x$ for communication with the honest server $B$, then $B$ has in fact generated $x$ and released it into the network (note that this gives no guarantee that $B$ intended $x$ for communication with $A$ in particular).

Applying this query to the different ProVerif code versions yields the following results:

• It does not hold for code version c030ut. The attack that ProVerif discovers is the first one described in Sect. 6.

• It holds for the code versions c030, c031, and c032.

Authenticity – Cookie. This query strengthens the guarantee acquired with the previous query: it ensures that if the honest client $A$ accepts a cookie $x$ for communication with the honest server $B$, then $B$ has in fact issued $x$ based on $A$’s public key, and has also encrypted the appropriate message with said public key. This is the query that corresponds to Goal 9.

The results for this query are as follows:

• It does not hold for code version c030ut. Authenticity for the cookie would require weak authenticity for it, which is not given (see above). Also, the Man-in-the-Middle attack described in Sect. 6 works on this version.

• It does not hold for code version c030. Again, the corresponding attack is the Man-in-the-Middle attack described in Sect. 6.

• It holds for the code versions c031, and c032

Secrecy – Cookie. This query asserts that if the honest client $A$ accepts a cookie $x$, then the attacker does not know $x$. This is realized via the event cookieCompromised() from the dedicated listener process as described in Appendix A.6. This query corresponds to Goal 8.

• This query does not hold for code version c030ut and neither does it hold for c030: Both of the possible attacks enable Mallory to make Alice accept a cookie that Mallory knows. In the case of the Blind-signature attack she manufactures said cookie herself; in the case of the Man-in-the-Middle attack she maliciously re-distributes a valid key, signed by Bob.

• This query holds for the code versions c031 and c032.

Next, we take a look at some queries that concern the time synchronization message exchange.

Sanity – Time Synchronization. This query checks whether it is possible for the protocol to be run such that the honest client $A$ successfully accepts a timesync response as valid and authentic from the honest server $B$.

This query holds for all four code versions.

Authenticity – Time Synchronization. This query ensures that if a timesync message $t$ is accepted by the honest client $A$ as authentic from an honest server $B$, then $B$ has really issued a message with the exact time data as in $t$ and secured it with the cookie which is generated based on $A$’s public key. This query corresponds to Goal 7.

• As might be expected due to the lack of cookie secrecy, this query also does not hold for code version c030ut and neither does it hold for c030. Since for these code versions Mallory can gain access to cookies that Alice accepts as valid, she can use those cookies to generate time synchronization packets with maliciously manufactured synchronization information that Alice will accept.

• This query holds for the code versions c031 and c032.