|
| 1 | +--- |
| 2 | +title: Frequently Asked Questions |
| 3 | +--- |
| 4 | + |
| 5 | +**1. How difficult is it to integrate TUF?** |
| 6 | + |
| 7 | + At a high level, all an adopter needs to do is (1) add TUF metadata to its |
| 8 | + software repository, and (2) arrange for clients to use TUF to fetch files |
| 9 | + from the repository before transferring the verified files to the software |
| 10 | + update system. |
| 11 | + |
| 12 | + In practice, (1) will also require the adopter to decide how to make the |
| 13 | + metadata and delegations available to clients, how to manage the keys needed |
| 14 | + to sign TUF metadata (in particular, how to generate, securely store or backup, |
| 15 | + and rotate offline keys), and how to periodically update and re-sign metadata. |
| 16 | + |
| 17 | + For (2), an adopter has to figure out how to ship the initial Root file, and |
| 18 | + implement [the TUF download and verification |
| 19 | + workflow](https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#5-detailed-workflows) |
| 20 | + in their language of choice if one of the existing implementations is |
| 21 | + insufficient. |
| 22 | + |
| 23 | +**2. Why should I use delegations?** |
| 24 | + |
| 25 | + Using delegations makes it so that users can perform actions for one another |
| 26 | + without needing to share keys in order to make this happen. |
| 27 | + As we state in the specification: "Delegated roles can further delegate trust |
| 28 | + to other delegated roles. This provides for multiple levels of trust |
| 29 | + delegation where each role can delegate full or partial trust for the target |
| 30 | + files they are trusted for." Delegations add more security. For instance, in |
| 31 | + a community repository like PyPI, delegating trust for target files to a |
| 32 | + project developer is recommended. It increases compromise-resilience because |
| 33 | + if the developers control their own project keys, an attacker cannot access |
| 34 | + them, and therefore cannot sign and serve malicious versions of the project. |
| 35 | + |
| 36 | +**3. What happens if the server and keys are compromised?** |
| 37 | + |
| 38 | + The repo maintainer must revoke and replace compromised keys. If a Timestamp, |
| 39 | + Snapshot, Targets, or Root key is compromised, the Root role must re-sign its |
| 40 | + metadata to replace the compromised key. If a threshold of Root keys is |
| 41 | + compromised, the Root file must be re-issued out of band. If a threshold |
| 42 | + number of offline keys are required, a full compromise of the repo is |
| 43 | + unlikely. For a more in-depth discussion about the steps to follow in the |
| 44 | + event of a key compromise, see [PEP |
| 45 | + 458](https://www.python.org/dev/peps/pep-0458/#in-the-event-of-a-key-compromise), |
| 46 | + which covers one way to deal with compromised keys on a community repo such |
| 47 | + as PyPI. |
| 48 | + |
| 49 | +**4. Can I use the same keys for different roles?** |
| 50 | + |
| 51 | + In general, you shouldn't share keys. In certain cases, even sharing online |
| 52 | + keys (e.g., between the Timestamp and Snapshot roles) is not advised. As we |
| 53 | + recommend for the PyPI community, "different keys for online roles allow for |
| 54 | + each of the keys to be placed on separate servers if need be, and prevents |
| 55 | + side channel attacks that compromise one key from automatically compromising |
| 56 | + the rest of the keys." |
| 57 | + |
| 58 | +**5. Which roles can use online keys?** |
| 59 | + |
| 60 | + The Timestamp and Snapshot roles can use online keys to facilitate continuous |
| 61 | + delivery of updates on the typical repository. All other roles should rely on |
| 62 | + offline keys to prevent attackers from signing for malicious packages in the |
| 63 | + event of a repo compromise. |
| 64 | + |
| 65 | +**6. What is the point of having the Root and Snapshot roles?** |
| 66 | + |
| 67 | + The Root role keeps track of the trusted public keys of the top-level roles, |
| 68 | + and can remove or add keys when needed. Its metadata is rarely updated and |
| 69 | + its signing keys must receive the greatest protection. In contrast, the |
| 70 | + Snapshot role is updated often, signed with an online key, and provides a |
| 71 | + consistent view of the metadata available on a repo. The Snapshot and Root |
| 72 | + role are responsible for different tasks that differ in level of importance. |
| 73 | + Separation of responsibilities is one of TUF's design choices. |
| 74 | + |
| 75 | +**7. Can you combine Timestamp and Snapshot?** |
| 76 | + |
| 77 | + There are a few reasons why the Timestamp and Snapshot files are not |
| 78 | + combined: |
| 79 | + |
| 80 | + * The Timestamp file is downloaded very frequently and so should be |
| 81 | + kept as small as possible, especially considering that the Snapshot file will |
| 82 | + grow proportionally with the number of delegated target roles. |
| 83 | + |
| 84 | + * As the Timestamp role’s key is an online key and thus at high risk, |
| 85 | + when an offline key storage is appropriate for Snapshot, separate keys should |
| 86 | + be used so that the Snapshot role’s keys can be kept offline, and thus in a |
| 87 | + more secure manner. |
| 88 | + |
| 89 | + * When rotating keys, it makes much more sense to rotate Timestamp |
| 90 | + frequently. When Timestamp is rotated, if an attacker compromises the new |
| 91 | + key, they can launch a freeze attack for a short while. For Snapshot, an |
| 92 | + attacker could cause clients to invalidate a lot of their stored targets |
| 93 | + metadata, which may result in re-retrieval of a substantial amount of |
| 94 | + information from the repository. So, it is recommended to rotate Timestamp |
| 95 | + more often. |
| 96 | + |
| 97 | + * Timestamp may be given to mirrors. |
| 98 | + |
| 99 | +**8. How often should metadata expire?** |
| 100 | + |
| 101 | + The Timestamp and Snapshot metadata should normally have a short expiration |
| 102 | + (1 day), whereas the Root and Targets metadata should expire less often (1 |
| 103 | + year). A good rule of thumb is the more often the metadata changes, the |
| 104 | + sooner it should expire. |
| 105 | + |
| 106 | +**9. Are there ways to reduce bandwidth costs?** |
| 107 | + |
| 108 | + It is possible to minimize the size and number of delegated metadata that the |
| 109 | + client has to download, and in doing so, reduce the associated costs. The |
| 110 | + [Metadata Scalability |
| 111 | + section](https://www.python.org/dev/peps/pep-0458/#metadata-scalability) of |
| 112 | + PEP 458 discusses in more detail the ways in which to reduce bandwidth costs. |
| 113 | + For example, if one large metadata file is split into several smaller ones, |
| 114 | + the bandwidth associated with downloading the large file many times can be |
| 115 | + saved. The reference implementation provides an [easy way to distribute |
| 116 | + target files across many targets |
| 117 | + metadata](https://github.com/theupdateframework/tuf/blob/d4b308ae13acfe832bfb7f993108e5e065d44c04/tuf/repository_tool.py#L2387) |
| 118 | + (i.e., delegating to hashed bins), which the |
| 119 | + [specification](https://github.com/theupdateframework/specification/blob/master/tuf-spec.md) |
| 120 | + refers to as path hash prefixes. |
| 121 | + |
| 122 | +**10. Can TUF be used with devices that lack the CPU power or memory to |
| 123 | + verify metadata?** |
| 124 | + |
| 125 | + At a minimum, a client device must be able to verify the hashes and |
| 126 | + signatures on TUF metadata. If a device isn't powerful enough to perform |
| 127 | + cryptographic operations or has limited memory, it can delegate verification |
| 128 | + of hashes and signatures to another device. For instance, a weaker device can |
| 129 | + rely on another device on the network to verify the signatures on top-level |
| 130 | + metadata. Delegating to another device is not built into the framework but |
| 131 | + [Uptane](https://uptane.github.io/), a variant of TUF, is designed to work |
| 132 | + with weaker devices like the Electronic Control Units found in automobiles. |
| 133 | + |
| 134 | +**11. Can I use TUF to download files from more than one repository?** |
| 135 | + |
| 136 | + TUF can download files from multiple mirrors and repos. In fact, we offer |
| 137 | + guidance for conducting a secure search for files across multiple |
| 138 | + repositories in [TAP |
| 139 | + 4](https://github.com/theupdateframework/taps/blob/master/tap4.md). |
| 140 | + |
| 141 | +**12. Has there been a security audit of TUF?** |
| 142 | + |
| 143 | + The [Security Audits](/audits) page links to a few of the security audits of |
| 144 | + TUF. |
| 145 | + |
| 146 | +**13. How can I try TUF?** |
| 147 | + |
| 148 | + The [Getting |
| 149 | + Started](https://github.com/theupdateframework/tuf/blob/develop/docs/GETTING_STARTED.rst) |
| 150 | + page contains instructions to install and run the reference implementation. |
| 151 | + The client and repo tools can be used to quickly create TUF repositories and |
| 152 | + experiment with software updates. |
| 153 | + |
| 154 | +**14. Is there a presentation or video about TUF?** |
| 155 | + |
| 156 | + The [Videos](/videos) page contains links to presentations that have been |
| 157 | + given by both TUF developer personnel, as well as adopters. |
| 158 | + |
0 commit comments