Software supply chain attacks are on the rise [34], with attacks more than tripling in 2021 [7] to over 30 per day [94]. One key link in the software supply chain is the software repository that distributes packages containing software libraries or applications to users. These repositories are often vulnerable to compromises, which can leave users vulnerable to attack [3, 4, 8, 25, 28, 32, 37-39, 66, 68, 69, 75, 78, 91, 92, 98-100, 103].
Contributing to this problem is the reality that most software installation tools download packages from multiple repositories. The top 10 Linux distributions come with an average of 4.8 default repositories from which users can install packages [5,6,72,102]. Such multiple repository congurations introduce unique security challenges. One such challenge is vulnerability to dependency confusion attacks [88] in which attackers upload malicious packages to a public repository such as npm, PyPI, or DockerHub [30,70,74]. A tool that downloads packages from both a private, internal repository and a public repository may install the attacker-uploaded package from the public repository if it shares the same name as one from the internal repository. This attack is possible because software installation tools lack a mechanism to specify which repositories are to be trusted for a given package. To date, dozens of companies, including Apple, Microsoft, PayPal, Netix, and Uber have been vulnerable to dependency confusion attacks [88]. On a broader level, the use of multiple repositories means that a key compromise can make any developer a single point of failure on a much larger scale. There have been numerous cases of developer account compromise in which benign packages were replaced with malicious ones [2,71,81,87,93,95,96].
Recognizing the magnitude of this threat, we present the rst systematic exploration into the security of multiple repository update systems that goes beyond the trivial k of n threshold signatures [35,86,89]. In response to what was learned, we introduce the novel concept of articulated trust which enables installation tools to selectively allocate trust in repositories, projects, or developers. Articulated trust moves responsibility for indicating requirements for package installation from the repository to the installation tool by giving installation tools the control to specically indicate which repositories and developers are trusted to provide each package.
To implement articulated trust we create Artemis, a new security framework that extends the functionality of existing Role-Based Access control (RBAC) models to multi-repository systems by incorporating a new suite of tools. These tools, including per-package prioritization of repositories, multi-role delegation, multiple-repository consensus, and key pinning, add user control and permit conguration of trusted packages. Though per-package prioritization is inspired by prioritized trust delegations [55,62,65] that allow a role to transfer its signing authority, Artemis permits users to dene prioritized and terminating trust relationships between all entities in the update process. Multi-role delegations and multiplerepository consensus expand the existing practice of threshold, or multi-signature, signing. Instead of just requiring multiple signatures on a signed object [12,29], it adds thresholds for other stages of the verication process. Finally, key pinning gives users more ne-grained control by specifying which individual developers on a repository should be trusted. Collectively, Artemis allows users to dene a greater diversity of trust relationships between objects and repositories, while removing single points of failure.
Artemis was created in response to, and in partnership with, industry demand, and as a result, we were able to deploy Artemis to resolve practical security challenges. In the automotive software update system Uptane, Artemis requires consensus between repositories that provide dierent security properties as a way to repel eorts by nation state attackers. Among other adoptions, Uptane is incorporated into Automotive Grade Linux, an open source codebase used in millions of vehicles. Furthermore, we examined the Cloud Native Computing Foundation (CNCF)'s Catalog of Supply Chain Compromises (CSCC) and found that Artemis's security properties would protect against all historical software repository attacks.
The contributions of this paper are:
(1) We conduct the rst exploration that focuses specically on the security of multiple repository update systems and identify the shortcomings of existing systems. (2) We introduce a threat model that specically addresses the risks of using multiple repositories, particularly when repositories allow unknown developers to upload packages.
(3) We propose a new approach for managing trust relationships called "articulated trust" that builds on Role-Based Access Control models including RBDM1 [11], and implement this approach in Artemis, a secure software update framework. (4) We back our claims by oering real-world examples of how our framework has been deployed to solve security challenges in multiple domains. Notably, Artemis is standardized as part of Uptane, and included in the CNCF graduated project The Update Framework (TUF). (5) We evaluate the eectiveness of Artemis using previous attacks on software update systems and nd that Artemis could have prevented all of them.
To provide context for our work, we rst describe the software update ecosystem. We then describe RBAC and The Update Framework, both of which serve as a baseline for our Artemis mechanisms.
A software repository is a server that hosts and distributes software. When a specic version of a software application or library is ready to be released, it is built into a package, and uploaded to the repository. Three groups of people may interact with the repository. Repository administrators manage the software and hardware, developers upload packages, and software installation tools download, validate, and install packages with a package manager. The software installation tool is congured by a tool administrator, who may be a user, IT department, or package manager. Software repositories vary in terms of their purpose and how they function. These include:
• Language-specic repositories such as PyPI, RubyGems, and npm.
• Operating system repositories, including those provided by Linux distributions. For example Arch Linux has 4 ocial repositories: core, extra, community, and multi-lib, each of which has a dierent set of packages and developers. • Curated repositories that contain packages for a particular purpose, such as for a company's internal use. They may be a subset of other repositories, include packages from multiple sources, or contain internal packages that are not public. A package manager is responsible for solving three problems: (1) downloading packages, (2) installing packages, and (3) performing dependency resolution [16,21]. The latter step ensures that all required packages are downloaded, and that there are no conicts between them.
Previous work [14,19] has shown that it is remarkably easy for attackers to tamper with les downloaded by package managers. As such, they are vulnerable to a wide variety of threats, including arbitrary software and replay attacks. An arbitrary software attack occurs when an attacker is able to convince a software installation tool to install a malicious package instead of the intended one. Similarly, a replay attack occurs when an attacker is able to convince a tool to install an outdated, potentially vulnerable, version of a package. Even when a secure transport mechanism like TLS is used, a repository or developer key compromise can allow an attacker to manipulate update contents. Thus, package managers require protections specic to this domain. Ladisa et al. [54] describe known attacks and safeguards.
RBAC is a technique for restricting system access to only authorized users by associating permissions with dierent roles [79]. Users are assigned to roles, inheriting the associated set of permissions. RBDM0 [10] (role based delegation model) extends RBAC by allowing roles to delegate their permissions to other roles for a xed period of time. Delegations may be revoked by the original members, or may be designated as terminating, which would prevent delegated users from further delegating this role. RBDM1 [11] builds on RBDM0 by setting up a hierarchy between roles and allowing the delegating role to give a subset of permissions to each delegated role.
The following is a list of the original RBAC96 components:
• U and R and P are sets of users, roles, and permissions, respectively • * ✓ * ⇥ ' is a many to many user to role assignment relation The RBDM0 model adds the following components:
• * $ ✓ * ⇥ ' is a many to many original member to role assignment relation • * ⇡ ✓ * ⇥ ' is a many to many delegate member to role assignment relation
Original members and delegate members in the same role are disjoint
in a role get all the permissions assigned to that role
gation to a single duration
The RBDM1 model adds the following elements: ' ✓ ' ⇥ ' is a partially ordered role hierarchy (this can be written as in inx notation). Also, the less familiar symbol k is used to denote non-comparability. We write G k ~if G¬ ~and ~¬ G.
When using RBAC in software repositories, the users are the developers, and the permissions are the set of package namespaces associated with a particular role. In this way, a role is responsible for a specic set of developers and package namespaces.
However, RBAC models are built on the assumption that this permissions model will not be tampered with. Should an attacker compromise the repository and alter the metadata that describes the RBAC permissions, they would be able to bypass these restrictions. To prevent this, researchers have created compromise-resilient software update systems [50,80].
A compromise-resilient software update system continues to provide the correct packages even when attackers control the repository and one or more signing keys [50,80]. The need to design such update systems was rst discussed in the literature by Bellissimo et al. [14] and Cappos et al. [19]. Knockel et al. [47] observed that attackers need not even compromise a repository: a simple man-inthe-middle attack on third-party software updaters is sucient to replace packages with malware.
The Update Framework (TUF) was designed for compromiseresilience [50,80]. It uses dierent roles [82,83] to sign dierent types of metadata, with each role requiring a threshold of < out of = signatures for acceptance. Thus, a single key compromise does not impact the security of the whole system. However, thresholds as a security measure only work for multiple users assigned to the same role. Roles A 2 ' are controlled by users D 2 * , such as repository administrators, developers, or organizations that release software.
A security feature of TUF is that it requires some roles to use ofine keys. In doing so, TUF ensures that an attacker with repository access cannot compromise the entire system. Oine keys are on physical devices and inaccessible from the repository, safeguarding them in the event of a repository compromise. We use a subscript to indicate the key for each role. So k of f denotes role A with an ofine key that is not kept on, or accessible from the repository, ⌫ k on denotes role B with an online key accessible from the repository, and ⇠ k indicates a key that may be either online or oine.
There are four top-level roles, each of which produces and signs metadata that fullls a specic purpose. Root provides a root of trust that delegates to all other roles. Targets provides information about images, or namespaced delegations to other targets roles. Namespaced delegations give a delegatee authority for a subset of the namespace, or set of package permissions ? 2 %, for which the delegating role is responsible. Finally, snapshot, introduced in a TUF variant called Mercury [50], provides bandwidth ecient consistency for the whole repository, and timestamp provides a heartbeat to ensure that all metadata is up-to-date and not revoked.
Delegations ensure that multiple parties do not have to share keys. To create a delegation ' k l , metadata signed by : indicates the public key ; and role name of the delegatee , as well as what portion of R's namespace = 2 % the delegatee is trusted to sign. ; can then sign metadata for targets in =. Diplomat [53], another TUF variant that, along with Mercury, has been integrated into the TUF specication, added prioritized and terminating delegations that ensure deterministic resolution by evaluating delegations in the order they are listed.
TUF is used in production by popular repositories, such as Docker Hub [30], Datadog [49], IBM [48], and the Python Packaging Index [51]. There are also multiple independent implementations of TUF, including those developed by Amazon [15] and Google [33].
A variant of TUF, Uptane [76], was created for use in an automotive context and has been standardized as a Joint Development Foundation project of the Linux Foundation. It uses the same RBAC principles as TUF, but the mechanisms dier in practice to account for the particular requirements of the automotive industry. However, the RBAC systems are equivalent and so for the purposes of this paper, the systems can be thought of as equivalent.
TUF addresses security concerns for users downloading software from a single repository, but does not account for the additional complexity of trust relationships between repositories. In this work, we apply the principle of compromise resilience to systems that use multiple software repositories, each with multiple developers.
Artemis was developed as a response to real-world concerns from software repository maintainers. We use scenarios to show the limitations of using existing software installation tools to install packages from multiple software repositories. The design requirements for Artemis were tailored to these identied problems.
Two repositories disagree on a package. Researchers discovered a vulnerability to dependency confusion attacks at PayPal due to the list of dependencies in an internal PayPal package's 'package.json' le. This list included both packages on npm and internal to PayPal. Researchers uploaded packages with the same name as the internal PayPal packages to npm, and these arbitrary packages were automatically installed [88]. When a tool installs a package foo, which is available on both an internal repository A and a public repository B, with dierent contents, it needs to determine which repository to download the package from. Many existing systems, like Pacman's repository conguration and Ubuntu's Personal Package Archive (PPA) [5,72], address this problem by prioritizing repositories. For example by rst searching in A, then B. As the roles on each repository are independent, every repository has a top-level role A 2 ', which has permission for all namespaces ? 2 %.
Yet, the tool might not always want packages from the internal repository. The company might have an unmaintained internal copy of a package bar, so that this package is listed on both A and B. When a vulnerability is discovered in bar and patched in the upstream version on B, the version in A does not receive this patch. In such cases, the update tool needs a mechanism to articulate that foo, which is maintained by the company, should be downloaded from A, but bar should be downloaded from B. The tool needs to prioritize the repository for each package or namespace ? 2 %.
Requirement 1: Per-package prioritization of repositories. The system must allow tools to assign each namespace = ⇢ % to a prioritized list of repositories in order to have a specic resolution for package downloads.
Installation tools only want some packages from a repository. In 2021, an attacker hijacked the developer accounts for npm packages coa and rc, leveraging these accounts to upload malicious versions of the packages. With over 20 million weekly downloads combined [2], these packages present a signicant attack surface. To counter this attack, a tool must be able to use certain packages from a public repository B while avoiding exposure to packages from untrusted or compromised developers [71,87,95]. Instead, tools must articulate a trusted set of packages and developers from repository B, ensuring that only these authorized packages are downloaded. When dening a set of trusted packages, tool administrators must balance the need to dene trusted developers with the risk of ignoring revocation information from the repository. This tradeo is further discussed in Section 7.2.3.
Requirement 2: Dening a trusted subset. Installation tools should be able to maintain a trusted set of roles ' and developers * on a repository to ensure the installation of only trusted packages from trusted developers.
Fallback problem. If repository A is unavailable due to a networking issue or a denial of service attack, even with repository priority the tool would fallback to B to download foo. Thus, the tool needs a way to prevent falling back to other repositories. In other cases, a company might maintain repository C as a backup copy of repository A. In this case, the tool should look for foo on repository A and C, but not B. This requires the tool to specify both repository priority and when a search for a package should stop.
Requirement 3: Terminate search for a package. The installation tool can dene when the per-package prioritization of repositories should stop the search for a particular namespace = ⇢ % Repository compromise. In 2018 PEAR, the PHP Extension and Application Repository, was compromised and an installation script was replaced with a malicious version, infecting all users for 6 months before the attack was discovered [73]. Such repository compromises are common, even for prominent organizations such as Microsoft, Debian, and Apache [3,4,27,28,68]. If a repository is compromised, the attacker can replace any package or delegation signed by online keys. To mitigate this a tool may want to require that all packages from repository A match those packages on repository C. If so, the tool needs a way to specify the repositories that must reach consensus before a package is installed.
Requirement 4: Mitigate repository compromise. The installation tool should be able to require a threshold of repositories to agree on the contents of a package.
Maintainer compromise. In 2022, the author of the popular npm package node-ipc intentionally published malicious versions as a form of protest [93]. In other cases, trusted maintainers have inadvertently uploaded malicious software due to a compromise of their accounts or signing keys [2,71,87,95,96]. TUF delegations allow delegators to revoke keys for these maintainers, but only after the attack is discovered. To prevent such attacks, tools need a way to not only ensure that a package is from a trusted maintainer, but also get third-party verication of the package contents from another role, such as a security scanner. This necessitates requiring a threshold of trusted roles agree on the contents of a package.
In current systems, if a role T creates delegations ) k of f l on and ) k of f ⌫ m on , and role A's online key ; is compromised, an attacker can maliciously replace a package with A's assigned namespace. Since the tool trusts T to sign this package, it will check if any delegation from T contains the package. As ) and A is assigned the package's namespace, the tool will install it. Instead, we want the tool to only install the package if it is signed by both A AND B.
Requirement 5: Mitigate role compromise. The installation tool should be able to require a threshold of roles to agree on the contents of a package.
Real-world use. Since Artemis is designed for real-world use, we also added practical requirements for smooth industry adoption.
Practical requirement 1: Shareable conguration. The end user may not be a security expert, and so should not make decisions about prioritization and threshold requirements. To address this, we ensure one expert within an organization can make congurations, then securely distribute them to all installation tools. Practical requirement 2: Preserve backwards compatibility with existing systems. We were surprised by the extent to which industry users valued backwards compatibility. Users of existing systems do not want to install new systems, but rather want to incorporate new security mechanisms into their legacy update systems. Therefore, any proposed solution must maintain backwards compatibility with existing systems designed for a single-repository setting. Otherwise, billions of downloads from these major repositories will face serious disruptions in service. [30].
Practical requirement 3: Mechanisms added must not signicantly eect performance. Any new features should minimally impact performance so that tools can easily integrate new security mechanisms. Specically, the mechanisms should not require signicant storage, download size, or computation time.
As security was paramount in our design, we establish a realistic threat model for software update systems in a multi-repository setting. We assume the following actors in our system:
• Repositories contain software packages and online keys used to sign metadata about these packages for timeliness and consistency.
• Developers upload software to repositories. • Repository Administrators control oine repository keys and repository conguration. • Software installation tools download software from repositories. • Tool administrators create congurations for software installation tools. • Users request packages through software installation tools.
We assume attackers can perform all of the following actions:
(1) Respond to user requests, either by acting as a man-in-themiddle on the network, or by compromising a repository. (2) Compromise one or more keys used to sign metadata, and hence packages, for a repository. These keys may be online, < k on or oine, < k of f . (3) Use a set of keys that has been compromised to perform arbitrary software attacks by replacing packages whose keys have been compromised with malicious versions. (4) Upload an arbitrary package to an unused name on a public repository.
An attack will be deemed successful if it convinces the installation tool to install a less-preferred or arbitrary package. Our goal is to achieve compromise-resilience in this setting, meaning an attacker may compromise some D ⇢ * , but not all, repositories or signing keys. Each compromise is bounded by the amount of time required for administrators to recover and restore the repository.
Although we focus on arbitrary software attacks, our system leverages existing software update security systems that can also address other attacks that occur on a single repository [17,[19][20][21].
The following problems are out of the scope of this paper, but have been discussed in other work:
• Denial-of-service attacks. TUF detects, but does not prevent denial-of-service attacks [80]. Other work has focused on denial-of-service prevention [105]. • Dependency resolution, or the problem of nding a complete set of packages that can be installed together without conicts. Many mechanisms exist to address this issue [16,21]. • Attacks on the software update supply chain before a package is uploaded to a repository, including source code security, continuous integration and delivery, and packaging.
in-toto, which has been used with this work, can provide supply chain security [43,49,101]. • Remote exploits, or a compromise of users' systems through a mechanism other than software updates. Such attacks could subvert software installation tools. • Attack detection. Artemis provides mechanisms to reduce the impact of an attack, and securely recover. However attack detection is out of scope, and can be performed by existing static and dynamic analysis and monitoring tools.
In order to address the threat model and requirements from Section 3, we extend the delegation model found in RBDM1 and TUF to implement articulated trust by adding multi-role delegations and user pinning of trusted roles. We apply this model to both roles on a repository and to the relationship between multiple repositories. An overview of the design is illustrated in g. 1.
First, we mitigate role compromise by introducing multi-role delegations. Unlike RBDM1's threshold signing that requires a threshold of keys, multi-role delegations require a threshold of roles, granting a subset of their permissions to multiple roles, but only if those roles agree. Multi-role delegations extend RBDM1 as follows:
• * " ✓ * ⇥ ' is a many to many multi-role group to role assignment relationship. • * " = * " 1 ^* " 2 ^... ^* " = for = 1 UAM consists of one or more sub-roles that must be in agreement on any action. • * " ✓ * ⇡ Multi-role delegations are part of UAD and contain the same properties described in RBDM0 and RBDM1.
In real-world applications, the RBAC model must be stored on the repository and communicated to users who perform verication. If an attacker compromises the repository or any online keys, they would be able to tamper with the RBAC model denitions. To address this, Artemis builds its role-based model on top of TUF's delegation model, which can prevent an attacker from undermining access control through the use of oine keys and revocation.
Figure 2 conceptualizes a multi-role delegation C0A64CB k of f ⌫>1 l on ^C4BC8=6 m on . If Bob's key l is compromised, the user will see that the secure hash listed by Bob for the malicious package does not match the non-malicious hash listed in testing and will abort the installation. Further, as targets is associated with oine keys :, either delegated role may be securely revoked. In order to replace Ubuntu with malware, attackers would have to compromise at least 4 keys across 2 roles.
Addresses Requirement 5: Mitigate role compromise. Multi-role delegations allow the tool to require agreement between multiple roles, preventing any role from being a single point of failure.
Next, we introduce a mechanism through which software installation tools can articulate a trusted subset of packages on a repository. We do so by pinning trusted roles, a process that can be dened as follows for a repository with a set of roles ':
• Installation tools dene ' * ✓ ', the set of roles they would like to use from the repository. • Any such that (⌫ 2 ' * ) inherits membership in ' * .
Dening ' * allows tools to locally dene the roles on a repository they would like to trust, which overrides any delegations listed on the repository. This protects against malicious repository maintainers, but puts the onus on the tool to keep ' * up-to-date. ' * is dened in the targets map le in Artemis. This le pins the roles ' * in a local directory alongside the installation tool. The software installation tool will use its existing verication process, Figure 3: The targets map le pins keys for specic delegated targets roles, using the pinned roles as the top-level targets and preventing tampering by a malicious repository. In this example, a targets map le pins keys for the Django targets role, so that the top-level targets and root on the repository are not used to determine keys used to verify this role. During software installation, only the highlighted roles will be used, limiting the repository to packages signed by the Django role. The repository's root is only used to determine keys for the snapshot and timestamp roles.
but will select and use only metadata from roles ' * , thus overriding roles and keys listed by the repository. Targets metadata les for roles in ' * must be present on the repository as they must be listed in its snapshot metadata. Figure 3 presents a targets map le that pins the delegated Django targets role.
One downside to pinning keys is that the tool cannot take advantage of automated key revocation from the repository. The tool denes ' * , and as a consequence these roles cannot be revoked by delegating roles on the repository. For this reason, targets map le users should ensure that they have up-to-date information about their pinned keys from tool administrators so compromised keys can be removed quickly. Tool administrators should ensure prompt updates of targets map le congurations, such as by using TUF to distribute the conguration. Tool administrators may also take advantage of delegations to update pinned keys by pinning a trusted role k of f that can further delegate to the roles used to sign packages. k of f is signed with oine keys, and so is more protected from a key compromise. Thus, k of f can later be used to revoke or replace the online package signing keys.
For example when a user knows the keys associated with a role 6 GHI , they may wish to reject any package that is signed with a dierent key EF1, even if the repository re-denes this role as 6 K L 1 . Using Artemis, the user may create ' * to pin 6 GHI 2 ' * so that a malicious repository cannot replace its key.
Addresses requirement 2: Dening a trusted subset. By allowing end users to dene ' * , key pinning gives the installation tool control over the trusted roles and developers. This ensures that the repository cannot alter delegations and gives the tool granular control over key revocation. In addition, key pinning prevents a tool from automatically trusting a new, malicious developer.
Finally, articulated trust addresses per-package prioritization and mitigates the impact of repository compromise through a secure conguration of multiple repositories. We extend the application of the multi-role delegation model to apply not only to roles within a repository, but also to the relationship between repositories. We dene Repository RBAC as an RBAC system in which the repositories are the users * ' , the namespaces are the permissions % ' and the roles ' ' are assigned a set of permissions and users. We apply the multi-role delegation model to Repository RBAC to allow for the same agreement between repositories as is achieved between roles.
The repository map le congures Repository RBAC in Artemis. It allows tool administrators to unambiguously allocate packages to repositories, preventing dependency confusion attacks and reducing the impact of a repository compromise. Each repository map le species * ' , % ' , and ' ' .
First, the map le contains a list of the available repositories * ' . Each repository is associated with: (1) a unique directory name where its metadata les are cached, and (2) a list of one or more URLs, each of which points to a root directory where metadata and packages are available.
Next, the map le species a list of repository mappings that dene the roles ' ' by associating namespaces % ' with each D 2 * ' . Similar to prioritized delegations [53], all repository mappings are listed in a descending order of priority. Each mapping species: (1) a list of one or more lename patterns, (2) a list of one or more repositories, and (3) a ag indicating whether or not the mapping Figure 4: A repository map le provides a ordered, prioritized mapping of repositories that restricts each repository to a namespace. Mappings are prioritized in order of appearance from top to bottom. In this example, all packages starting with mysql-custom package are downloaded from A and all other MySQL packages are downloaded from B. This is combined with a multi-role delegation to repositories C and D for ubuntu packages. A compromise of a repository will be limited to the namespace assigned to that repository. is terminating. Akin to terminating delegations [53], a terminating mapping signals to a software update security system that it should halt its backtracking search for a package (described in Section 6.1), so the user should ignore any delegation ⌫ from a terminating role . Since repository mappings are strictly ordered, there will always be one trusted conclusion for a package's metadata, or none at all if no set of trusted repositories has signed the package.
Finally, the repository map le contains a multi-role delegation threshold that species the number of mappings that must agree on the contents of a package. The tool will search the prioritized repository mappings until the designated threshold of mappings agrees on the package contents. This threshold gives the user protection from malicious maintainers or a repository compromise.
For repositories 2 * ' and ⌫ 2 * ' assigned to roles ' and ' ⌫ , respectively, Artemis can specify that namespaces 0 2 % ' should be assigned to ' , 1 2 % ' should be assigned to ' ⌫ , and 2 2 % ' should be assigned to ' , then ' ⌫ . Thus, a package in namespace 0 will only be downloaded from repository , while a package in namespace 2 will be looked for rst in , then in ⌫. Figure 4 provides an example of a repository map le.
In this way the tool is able to provide per-package prioritization of multiple repositories, preventing dependency confusion attacks. Packages on trusted internal repositories cannot be replaced with arbitrary packages from a public repository, as these repositories are assigned dierent permissions. A tool is able to maintain a collection of veried or proprietary packages, while safely taking advantage of existing public repositories for other packages.
Addresses requirement 1: Per-package prioritization of repositories. Artemis explicitly allocates trust for each package by using prioritized repository mappings that specify which repository should be used for each namespace ? 2 % ' .
Addresses requirement 3: Terminate search for a package. The repository map le allows any assignment to a repository to be terminating, so that the tool will stop the search for a namespace =.
Further, the repository map le can create multiple repository consensus. A tool may use a multi-role delegation in Repository RBAC from the root role A 2 ' ' for repositories 2 * ' and ⌫ 2 * ' . So A ' ^'⌫ . A tool will automatically reject a package if the hash of the package downloaded from repository A does not match that of the package downloaded from repository B.
Addresses requirement 4: Mitigate repository compromise. The thresholds in the repository map le allow the tool to ensure that multiple repositories agree on package contents, and thus prevent any repository from being a single point of failure.
We integrated Artemis into TUF and Uptane, and our implementation 1 has been upstreamed into production use. There are dierent implementations for each integration, using some or all of Artemis's features. These implementations include an integration in Scala for Automotive Grade Linux, as well as libraries in go and Python.
In the python-tuf integration, adding all features of Artemis only adds about 150 lines of code to the existing 3500 line codebase. Processing the repository map le added about 100 additional lines and the targets map le about 50 lines. This does not include additions due to unit tests, integration tests, and documentation.
Our implementation adds the repository and targets map les, which require no changes to the repository, and thus preserve backwards compatibility as specied in Section 4. As these new le types are not signed, they can be distributed by a tool administrator to a user using TUF or another secure distribution mechanism. Map le examples are shown in Appendix A.
Multi-role delegations are implemented on the repository by adding a min_roles_in_agreement eld to delegations and allowing each delegation to list multiple roles. The user must ensure that at least min_roles_in_agreement roles have signed the same le hashes for a package.
Artemis requires the following workow for downloading and verifying software. First, the software update security system loads the repository map le and iterates over the list of mappings. Then each is processed using the following steps:
(1) If the lename of the desired package matches one of the paths in the list of lename patterns, then go to step 2. Otherwise, go to step 5. (2) Download and verify the metadata for the package. The metadata will contain the hashes and length of the package.
(3) If the package hashes and length match across a threshold of repositories, then download the package, verify that it matches this metadata, stop the search, and return it. (4) If there is no metadata about the package from any of these repositories, or if this is a terminating mapping and the package hashes and length do not match across these repositories then stop the search, and report that the package is missing. (5) Continue to the next mapping. In step 2, the software update security system will use its established workow to download and verify metadata from each repository, unless the targets map le is used. In the latter case, the system will only use ' * and therefore the keys assigned to ' * . These roles may then delegate to other roles on the repository. The system will verify only packages signed by roles in ' * , or a delegatee of ' * . All other security checks are done using metadata provided by the repository.
Once it has established which repositories and keys should be used, Artemis uses a pre-order, depth-rst search [53] to resolve prioritized and / or terminating delegations, and nd metadata for the package. When multi-role delegations are used, Artemis modies this search only by ensuring that the package hashes and length match across multiple, prioritized roles.
We tested Artemis in two ways. First, we analyzed past attacks to see how Artemis can prevent or minimize assaults on software update systems. We also evaluated how the mechanisms of articulated trust contribute to achieving our security and usability goals.
To evaluate Artemis, we examined attacks from the CNCF's CSCC [85]. This catalog oers a cross-section of the many types of attacks on supply chains, with a particular focus on cloud applications. Of the 59 attacks cataloged before October 2022, we analyzed only those that targeted software update or distribution systems and sorted them by type of compromise. These attack types are:
• Repository compromise: The attacker gained control of the software repository.
• Compromised developer key: The attacker compromised a developer's signing key or account. • Compromised key and repository: The attacker compromised both a signing key and the repository. • Compromised key of another trusted developer: The attacker gained control of a trusted key for a developer other than the one who usually signs the aected package. • Redirect to attacker repository: The attacker convinced users to download updates from a malicious repository • Malicious new developer: A new developer joined the team or took over the project, then performed the attack. • Malicious existing developer: An existing developer performed the attack. Table 1 shows the relative eectiveness of TLS/GPG, Sigstore [90], TUF, and Artemis in preventing these attacks. Even with the usability gained from online keys, Artemis with a threshold of at least 2 roles and repositories would have prevented all 29 attacks. A conguration of Artemis without all features would still allow
TUF Artemis w/online targets Artemis w/oine targets Attack Type Count GPG/ TLS Sigstore Online targets Oine targets Key pinning Multi-role delegations Repository RBAC Key pinning Multi-role delegations Repository RBAC Repository compromise 13 ⇥ # # # Compromised key and repository 3
Table 1: Evaluating attack protection of dierent software update security systems, including a breakdown of protections provided by each of Artemis's features. ⇥ means that the attack is not prevented and there is no way to securely recover after an attack. # means that the system can recover from, but not prevent an attack. G # means that the attack will be prevented if a threshold C > 1 is congured. means that the attack is prevented.
users to recover from all classes of attacks analyzed by revoking compromised keys. Conversely, software update systems that rely solely on online TLS/GPG signatures would not have prevented the analyzed attacks. While TLS/GPG do provide some protection, they are so common in real-world applications [44] that recent attacks have bypassed this protection. The Sigstore project, which stores signatures on a transparent log, provides recovery from 22 analyzed attacks, but only prevents 2. Systems that use TUF with an online targets role are able to prevent 4 attacks, with high thresholds preventing a further 9. TUF is able to recover after any of the remaining 16 attacks, but could not avoid being compromised. Oine keys in TUF prevent an additional 13 attacks.
Since Artemis is designed for modular implementation, we breakdown which security properties of Artemis defend against each attack type. Key pinning, which prevented 18, allows users, rather than repositories, to specify trusted keys. Thus, key pinning prevents attacks that rely on changing trusted keys. In these attacks, an attacker manipulates the trusted keys for a package by changing a delegation. With key pinning, the user will ignore delegation changes that come from the repository or untrusted keys. This includes attacks performed by malicious new developers as key pinning allows the tool administrator to vet new developers. Multirole delegations, which prevented 13 with online keys and 29 with oine keys, requires a threshold of at least two roles or repositories to agree on package contents, preventing a single role or repository compromise from leading to a successful attack. If a single role is compromised and provides metadata for a malicious package, the uncompromised role will not agree with anthey malicious package contents, and so the user will not install it. Finally, repository RBAC, which prevented 20, allows the user to specify which package should come from each trusted repository and developer, thus limiting the impact of a compromised developer or repository to the packages they control.
Not all systems that use Artemis choose the most restrictive conguration, so in practice its level of protection will depend on the chosen security properties and thresholds. For example, thresholds will only provide security gains if they are larger than one. Based on Table 1, a combination of multi-role delegations and repository RBAC could have prevented all the considered attack categories. However, this assumes that all roles and repositories have thresholds greater than one, which is not practical in all deployments.
Adoption requirement Deployment Artemis features Congured by Dene updates for each vehicle Automotive OEM Protection from repository compromise Automotive OEM Gather updates from multiple suppliers Automotive OEM Using a third party container registry Cloud Package manager Store sensitive data on a private repository Cloud Company Use software from a public repository Cloud Package manager Ensure updates are tested Cloud Package manager
Table 2: Dierent Artemis deployments use dierent features, often in combination to achieve specic requirements.
It should be noted that the property of per-package prioritization provides protection against attacks that specically target multiple repository systems, including dependency confusion attacks, which are categorized here under redirect to attacker repository. Further, some of the properties in Artemis are designed to work in combination. For example, multi-role delegations work best when attackers cannot replace the delegating role . To mitigate this, a user may either pin developer keys by specifying ' * ✓ ' such that 2 ' * , or utilize oine keys for for additional assurance.
Artemis has been adopted in the Uptane Standard [76], which is used by automotive companies in Europe, the United States, and Japan. There are also public deployments by HERE Technologies, Airbiquity, Foundries.io, and Automotive Grade Linux [46]. Further, TUF, which is used in production by Datadog, AWS, Google, Docker, and others [18], uses Artemis to support container registries. The properties archived in these deployments are summarized in Table 2.
7.2.1 Automobiles. Artemis's multiple-repository consensus resolved Uptane's requirement to protect against nation state attackers while preserving customizability. With online keys, repositories can instantly sign dierent updates for dierent vehicles. But, online keys are much more vulnerable to compromise. Alternatively, signing software updates using oine keys provides better protection in the event of a repository compromise, but makes it harder to implement customized updates. Thus, use of oine keys can interfere with eective and time sensitive updates.
To solve this issue, Uptane uses multi-repository consensus to separate responsibility. The Image repository uses oine keys to sign metadata about all images. The Director repository uses online keys to provide instructions about which images should be installed on each vehicle. Putting these together, Artemis delegates from the root role A ⇡8A42C>A d on ^ <064 i of f . As the two repositories are independent of each other, attackers are unable to install malicious images unless they compromise both. This ensures that attacks on online keys are insucient to install arbitrary packages, while allowing for on-demand customization.
Additionally, multi-role delegations allow automakers to collect updates from a number of suppliers without sharing private keys.
Key Takeaway: By using both multi-repository delegations and multi-role delegations it is now possible to ensure a software update system can remain resilient even against an actor, like a nation-state, that can compromise all repositories and online keys. 7.2.2 TUF. Artemis allows TUF to facilitate updating images from multiple container registries. A container is a form of OS-level virtualization that provides relatively isolated environments for running software. Containers are often packaged as images, or immutable snapshots of the container lesystem, hosted on repositories known as container registries, such as Docker Hub [30] and CoreOS Quay [26]. Using Artemis, users can dene prioritized and terminating mappings to each registry, and specify trusted developers and packages when using an untrusted registry.
Enterprises such as eBay use Quay to distribute images to avoid the cost of hosting and maintaining its own repository. However, eBay may trust Quay for its own images, but not those of other developers. Also, eBay does not want Quay to be able to create delegations that could replace their trusted keys. Dening a trusted subset with Artemis addresses this concern.
Per-package prioritization supports enterprise users. Enterprises cannot risk uploading images to public repositories that may expose sensitive or proprietary information. Even if access controls are placed on the images themselves, it is likely sensitive information, such as le names and public keys, will be revealed through metadata. Artemis's repository mappings allow enterprise users to store sensitive data on a private repository while taking advantage of public repositories for less sensitive images.
Key Takeaway: Key pinning and per-package prioritization allow users to trust some, but not all, packages on a registry and download these packages without trusting registry maintainers. 7.2.3 Lessons from Deployment. The initial deployment of Artemis required an investment of time from repository administrators. Systems that already store TUF metadata alongside packages require fewer changes, and so Artemis could be deployed in these systems more easily. The modular nature of Artemis allows administrators to implement features incrementally, and decide which features would provide the most security for their implementation. Uptane implemented both multi-role delegations and repository RBAC in order to support consensus between multiple roles and repositories. Conversely, users of community package repositories can implement just repository RBAC and key pinning in order to support per-package prioritization and reduce trust in the community repository.
Once Artemis is implemented, trust needs to be established in roles and repositories. Artemis uses TUF to establish trust, with the root role distributing keys for other trusted entities. This also provides mechanisms to revoke and replace trusted parties [19,50]. TUF can further be used to distribute map les required by Artemis. A separate TUF repository with a trusted root could distribute the map les to a software installation tool. If any trusted party is later found to be malicious, TUF provides mechanisms to revoke trust. Further, role and repository thresholds in Artemis reduce the impact of any single compromised role.
Artemis requires a trusted administrator to set up and manage the security and usability tradeos of thresholds and pinned targets. Once these congurations are made, they can be shared among users. In Uptane, these decisions were made primarily by automotive OEMs, who determined the threshold of repositories in the repository map le, and then pushed this conguration to vehicles. In container implementations, the conguration was done by the package manager, company, or individual user that could set thresholds or pin targets based on their particular threat model. The default conguration for a package manager is shipped along with the software.
There are tradeos to consider when setting thresholds to balance the increased security of having more developers or repositories agree on a package's contents, and the potential for a failed update if a threshold is not met. In the case of an insucient threshold, the tool must decide whether it is more important to meet the threshold or to install the package. For example, a tool could choose to not install the package if a signature from the original developer or a security team is missing. However, a missing signature from the QA team may be congured to not block installation. This decision must be made by looking at the purpose of each required role and the threat model of a particular application. If a threat model contains nation-state attackers that can compromise a repository or signing key, a high threshold that includes oine keys should be used. For Uptane, a threshold of two repositories allowed automakers to balance the need for real-time conguration with the need for oine keys. For applications used for hobby projects, a threshold of one may be sucient. Community package repositories aim to make packages easy to distribute, and so would only require a single role to sign a package, removing barriers to adoption.
Artemis also achieves the practical requirements from section 3.
Shareable conguration. The map les that Artemis introduces can be easily congured by experts and distributed to endusers. Map les should be distributed with TUF or a similar mechanism to ensure that the tool's copy is current and accurate. These les are designed to remain accurate as new packages are uploaded to a repository. They only need to be updated to change the trusted set of developers or policies for a package.
Backwards compatibility. As Artemis does not change the underlying techniques of TUF, it continues to prevent known attacks on single repository update systems [50,52,80] including replay attacks on metadata and packages. This also ensures backwards compatibility with existing TUF users. Software installation tools may add targets and repository map les as client-side conguration with no changes to repositories. However, multi-role delegations do require a change to existing metadata formats. To ensure that software installation tools do not encounter unfamiliar metadata, this change should be supported rst by software installation tools, and then by developers uploading to repositories. This may be done through API versioning on the repository.
Performance. Based on performance tests of the Python implementation, Artemis adds minimal processing time to software update systems. We compare runtime and metadata sizes with and without repository and targets map les. For this test, the repository map le requires that two repositories agree on package contents. Our results are summarized in Table 3 and show only an increase of 10 milliseconds for verication. If more repositories or roles are veried, there would be more processing, but this increase is still small for users considering that downloading and installing software packages, which are often many megabytes in size, dominates the overall processing time. For example PyPI packages, based on publicly available data, average over 3MB [104].
The Python implementation of Artemis is built on top of a TUF implementation, and so has similar performance as the size of repositories grows. An analysis of the runtime and metadata overhead of TUF was performed in Mercury [50].
Artemis can enhance security protections with a manageable change to existing systems. Our implementation added only about 4% more code to the software update system. The simplicity of the additional code required for verication makes it easy to implement.
We compare Artemis to the broader eld of software supply chain security, as well as other work built on in this paper. Software supply chain security Artemis improves security of software distribution and updating, a sub-problem of software supply chain security. Other technologies in this eld solve related problems. in-toto [101] is an end-to-end framework that allows users to dene and validate steps in a supply chain. Software bills of materials (SBOMs) [97] provide auditable information about software dependencies including Software Identication (SWID) tagging [23], Software Package Data Exchange (SPDX) [106], and CycloneDX [31]. Coppens et. al. present binary code diversication to prevent attackers from using binary dis to reconstruct patched attacks [24]. These technologies can work in tandem with Artemis, with Artemis securely distributing both packages and metadata, like SBOMs, from other supply chain security technologies. Han et. al. introduce Sigl, a tool for detecting malicious software installer programs [41]. Artemis focuses instead on ensuring that the installer gets the intended artifact from a collection of software repositories.
Multi-role delegations. Artemis applies ideas from previous work in logic-based distributed authorization. D2LP is an authorization language in delegation logic [40,61,63,64] that extends early works on trust management and authorization in distributed systems [1,56]. D2LP also uses both the AND and OR relations in delegations, and could express the mechanisms in Artemis. However, Artemis is the rst system for software updates that uses these types of delegations.
Threshold and multi-signature signing Artemis expands on the idea of signature thresholds by adding thresholds of roles or repositories. Multi-signature signing [13,45,57,67,77] eciently allows multiple signatures on an artifact. Threshold signatures [35,86,89] allow multiple parties to sign an artifact by splitting the private key among all entities. Artemis does not require that the same metadata bytes are signed, but that the hashes and length of a package match across multiple roles or repositories.
Multiple repositories. Like Artemis, other systems use the idea of multiple repositories or servers, but there are some important dierences. Linux software updaters dnf and apt allow users to install packages from multiple repositories as does Revere [60], which uses a self-organizing, peer-to-peer (P2P) overlay network to deliver updates. Essentially, every Revere node acts as a mirror, and may push or pull updates to or from other nodes. However, these systems do not solve the priority or fallback problems, or allow for multiple-repository consensus.
Byzantine fault-tolerant systems (BFT) use many replicas instead of a single server to execute operations [9,22,59,84]. Yet, BFT systems are aiming to solve a dierent problem, that of guaranteeing linearizability [42] in a system made of distributed processors. In contrast, Artemis uses multiple repositories as independent sources of information that must agree with each other.
Reducing trust in a repository. Some software update systems allow users to reduce trust in a repository. For example, apt and dnf require user permission before revoking and replacing keys used to verify metadata. However, Artemis is the rst system that removes the repository from the equation. Instead, Artemis allows users to specify their own keys for packages and metadata. This technique is powerful enough that it can solve other problems, such as reducing trust in mirrors.
Secure Untrusted Data Repository (SUNDR) [58] uses a set of trusted users that honestly report histories. SUNDR uses this information to detect equivocation to protect against arbitrary software attacks and forking attacks on a single repository. Artemis does not rely on a trusted set of honest users reporting history data and also supports articulated trust in multiple repositories.
Another approach to reducing trust is the use of binary transparency through publicly auditable, immutable transparent logs. Sigstore [90] provides a set of tools for signing packages and uploading these signatures to a transparent log for auditability and protection against forking attacks. But, this approach relies on thirdparty auditors of the log. Artemis is compatible with transparent logs, and and there are integrations of Artemis and Sigstore [90] that provide Artemis's articulated trust and revocation mechanisms in addition to the protections oered by transparent logs.
Ghosn et. al. [36] propose reducing the impact of malicious packages by using Enclosures to restrict the resources that library dependencies can access. Unlike Artemis, Enclosures require changes to programming languages. Artemis can work with existing developer workows, and would be compatible with Enclosures.
In this paper we conducted the rst comprehensive examination of the security of multiple repository update systems. We introduce articulated trust to enable a software update system to use multiple repositories while limiting the trust placed in them. Artemis, our implementation of articulated trust, has been successfully deployed in several large scale production environments. Artemis uses simple yet eective mechanisms to provide secure conguration of trust in challenging environments, such as automobiles and container registries. Through collaboration with industry practitioners, we show that Artemis addresses real world problems. For example, Artemis allows companies using popular cloud container sites to prevent dependency confusion attacks. It also helps automakers enhance their resilience against nation-state actors through multiple-repository consensus.
The security properties of Artemis are very eective in preventing previous attacks on software update systems, and would prevent all attacks that we analyzed, compared with 59% for TUF and 7% for Sigstore. By employing key pinning, eliminating single points of failure, and per-package prioritization, Artemis establishes a robust defense against attacks on multiple repository update systems.
https://github.com/mnm678/artemis-artifacts