IEEE 1588 (PTP) Security

In my master thesis I studied the security aspects of the IEEE 1588 protocol: Precision Time Protocol (PTP). What started as a threat analysis soon became a threat analysis, attack demonstrations and a suggestion for a complete security solution for the protocol. The short version of the article was presented in the ISPCS 2016 conference, and the full version can be found here.

What I found unique about my research wasn’t it’s results, although we did present several new vulnerabilities and proposed mitigations. The unique aspects were actually our method of research, as will be detailed explained in this post. The following chapters will summarize the research plan used in my thesis, alongside several examples for of the advantages it gained us, and the pitfalls we missed because of it. It is highly recommended to read the full article in order to better understand the next chapters.

1. Study the technical background

Since the IEEE 1588 standard was already in it’s 2nd version, there was plenty of reading material for studying about it. During this stage it is important to dive into the small and technical details, as will be proven useful later on. For example:

• The sequenceId field in the protocol’s header had a dominant part in the proposed network mitigations – and was never before suggested or used for security purposes.
• The protocol consists of 3 main layers, a fact that strongly affects the overall security solution that should be defined for it.

2. Study the security background

Except for the experimentally Annex K, the protocol had no built-in security mechanisms. Combined with the fact that the 1st standard was released way back in 2002, it is quite obvious that the protocol will receive some security related attention. During this stage it is useful to try and classify the security articles into groups such as: event message attacks, link layer security layers, etc. This classification can help later on in two main research questions:

1. What security aspects have gone unnoticed, and should be studied?
2. Why have they gone unnoticed, and what should be done differently?

In my case it was quite clear from the start that this stage will be the crucial part in distinguishing my research from prior work. For example:

1. Prior works mainly focused on attacks against the protocol’s event messages, and only partially against its leader election algorithm. Meaning that only 1.5 layers of the protocol, out of 3 layers overall, received prior security attention.
2. The answer for this question can be found in the next research stage.

3. Define the security goals

Instead of jumping straight ahead into the attack vectors, or proposed mitigations, we should first start in defining what is actually important to protect, and how much it is important. Now when we already have a knowledge of the technical background, we can translate it into short and clear security goals:

1. Keeping the legitimate nodes’ time integrity
2. Keeping the integrity of the BMC hierarchy
3. Keeping the authenticity of the management node

As it turned out, we have a security goal for each layer of the protocol.

4. Preform a threat analysis

This is a cyclic stage that should be preform after every mitigation step is introduced, until it converges to a satisfying state. Each iteration consists of 3 main steps:

1. Define the assets: what do we want to protect? what can help an adversary?
2. Define the adversaries: where are they positioned? what do they know? what can they calculate? what can they intercept? what can they transmit?
3. Define the attacks: practically a Cartesian product of an adversary with X assets that wants to achieve / harm Y more assets.

When presenting the adversaries in the PTP scenario we introduced several novelties:

• Differentiation between several outsider adversaries
• Introduction of the outsiders VS insiders adversary groups
• Pointing out to some all-powerful adversaries that should be taken into consideration

5. Plan a security solution

Only after the first 4 steps are completed there will be enough knowledge of the reasons for the security vulnerabilities in the current system. In this stage we can address these vulnerabilities, while trying to devise a security solution that will take into consideration all of the system’s aspects and goals. For example:

1. The PTP time messages has no secret content, only their integrity is important. This integrity was achieved using a cryptographic signature, thus making prior encryption/decryption patents, see link, quite useless.
2. The protocol has 3 distinct roles: Manager, Time Costumers and Time Distributors. Symmetric cryptography alone won’t be able to distinguish between the latter two, therefor we introduced a Public Key-based security solution.

Conclusion

Here is a good example that summarizes the advantage of following the proposed research steps, instead of defining the security requirements solely based on a candidate security solution:

This table shows our security solution according to the security requirements defined in RFC 7384. As can be seen, the RFC was defined with a symmetric crypto solution as an “already thought about” solution. This makes the “Key freshness” security requirement quite irrelevant when referring to our public key based solution.

I hope that the proposed research steps, steps that I learned from great teachers throughout the years, were made clear using my thesis as an example. And I further hope they will be useful for any other security researchers in the future.