The issue of Root key loss and trust chain reconstruction

[Jianming Xu]

When applying the TUF framework to vehicle software updates, we encountered an issue: once a certain number of Root keys are lost, we assume that attackers have installed malicious software and taken control of the affected vehicles. In such a scenario, to reinstall the correct software, the only option is to recall the vehicles. This cost is unacceptable for the automotive industry.

To illustrate, let's consider a singular root key for the problem description. Starting from 1.root.json:

1.root.json -> 2.root.json -> 3.root.json -> 4.root.json

Suppose at step 4, the root key is lost. A hacker uploads a malicious software package, "bad_software," and generates 4.root.json. The vehicles update to 4.root.json, downloading and installing the malicious package, "bad_software." In this situation, the only recourse to reinstall the correct software package, "good_software," is to recall the vehicles.

Even if we were to update the root key, upload the correct software package "good_software," and regenerate 4.root.json and other metadata files, the vehicles still couldn't complete the update. This is because the vehicles hold the 4.root.json signed by the hacker and won't automatically download the latest, correct 4.root.json, preventing the software package replacement. Even if we generate a new version, 5.root.json, it won't pass verification because it's not signed by the 4.root.json saved in the vehicles, rendering the software package replacement impossible. Consequently, our only recourse is to recall the vehicles and manually replace (rewrite) the software. However, for a vehicle enterprise with millions of vehicles, this cost is unacceptable.

We've come up with an efficient solution and want to know if the TUF experts would approve. 

Our approach involves restarting the trust chain from 1.root.json and wiping all root metadata files on the vehicles. This way, the vehicles reconstruct a trusted chain relationship, ensuring the safe and proper installation of software.

thanks

Jianming

[Justin Cappos]

I'm curious to know more about the threshold you are choosing for root keys and the frequency with which you rotate them.

I'm also not sure what you mean by the fact that a root key is lost...  How and when would an attacker gain access to this?  In practice, we've not heard of this happening due to the way the root keys are typically stored and managed (see below).

As I understand it, most organizations often have ~5 of these and need a threshold of 2 or 3 to sign something.  They are typically hardware keys (e.g., a Yubikey kept in a safe), and are not just sitting on a server or laptop.  Root keys are rotated, or at least used, every 6 months or so, mostly to ensure that the key material hasn't been lost.

One important reason why the root keys can be rotated (and are no longer trusted after rotation) is that there have been many cases where generated keys were later found to be weak or we inadvertently exposed.  So, continuing to trust a threshold of root keys from root.1.json after the root keys have been rotated multiple times would pose a lot of risk.

For example, in your design, what if a threshold of the root.1.json keys had been generated using the flawed RSA code used in Debian?  Anyone in the world could then write a new version of metadata and harm all of your vehicles.  Similarly, once we are in a post quantum crypto world, if you were deploying classical crypto algorithms, you need a way to rotate them out.  In this case, you don't have a secure way to make that transition.

Thanks,

Justin

--
You received this message because you are subscribed to the Google Groups "The Update Framework (TUF)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to theupdateframew...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/theupdateframework/50ba17ad-1376-48c7-9a46-70a8cff9eb19n%40googlegroups.com.