 Say hello, everyone. I'm Marina Moore. I'm a PhD student at NYU in the Secure Systems Lab, working with Justin Capos and many others on tough and other projects. My co-presenter, Joshua Locke, unfortunately, was not able to make it here today, but I want to give him credit for help with the slides and everything else. All right. So what are we talking about today? Content repositories. So content repositories, basically just any kind of collection of content, usually somehow able to be addressed by a user, often with various different versions of the content all stored in the same place and accessible. So as a quick example of what one of these can look like, we have various different packages stored on the content repository with different versions of the package, all associated with the name of the package. And there's also an index which then points to all of these different, all the different content on their repository, which the user can then talk to this index to either find the name of a package that they're looking for, or the most recent version of a package or a specific version. The index will then point them to a path to the exact image they want to install, which they can then query and get onto their machine. Kind of an overall view of how that works. However, as with as with many systems, there are a lot of things that can go wrong if pieces of the system are attacked. So if an attacker is able to gain access to this index, they're able to change either the location of the package that you're going to download, or they're able to change the version that you're going to download and maybe show you an older version that maybe has known vulnerabilities or some other problems, or just show you different versions of different packages that were never available at the same time. And these different versions could maybe have some incompatibilities that can lead to other vulnerabilities. And then when you request from this malicious index, it'll give you a bad path or some path that you're not expecting when you want to download this piece of content. Another thing that can go wrong is you can be redirected to a whole another place to download the package. And that can also be a bad way to go. And in addition, the entire content repository itself can be compromised in any of these different pieces of content on this repository can be replaced with malicious versions of these packages and artifacts or whatever it is that's being stored. And this has happened in practice. There have been, this is a collection of some recent attacks that have used software update systems as a vector for distributing malware to users. And these continued happen in practice. And it's not due to a lack of smart people working for all these various different places. This is just a very tempting vector for attackers because it's a place where you're installing a piece of software and then going to run it on your machine. And so if the attacker can mess with what you're installing, it's a very tempting thing for them to do. So what can we do to prevent this from happening to you? This is where the Update Framework or Tough comes in. It's a framework for secure software updates that's designed to protect the freshness, consistency, and integrity of packages. And it does this at the same time as reducing the impact of a compromise and allowing for recovery when a compromise does happen. So in a bit more detail, so Tough protects content by using cryptographic signatures in a couple of different places. It has signatures that go over the content itself in order to protect the integrity of the content that you're downloading. It also has signatures over the entire repository or an index into the entire repository in order to protect the consistency of the different things that you're downloading from the repository. And finally, there are signatures over a heartbeat with a short expiration time in order to prove freshness of the metadata and the content that you're installing to make sure that you're not seeing old versions that may be malicious and or non-intended. Tough also reduces the impact of key loss through a couple of different mechanisms. It separates responsibilities so that no single role or key is responsible for signing all the different content. So one key has one responsibility and another key has another responsibility. So if any one of these keys is compromised, it only compromises that one responsibility, which in most cases isn't enough to convince someone to install malware. And in order to have additional protection, each of these roles can also have a threshold of keys. So you don't just have one key signing for a single, for example, piece of content. You could have multiple different keys that are required to sign the same piece of content and they should agree on what's in that content so that when they're all verified, you can see that, okay, it's not just this one entity which may be compromised that thinks that this is true, it's also various other entities as well. And this can also be nice for ensuring some processes followed. So for example, if there's a code review process that you want to ensure a certain number of people have reviewed the code before it goes on to the next step, you can kind of enforce this through requiring a threshold on that. And finally, Tough balances the trust and responsibility by ensuring that the more vulnerable roles have less of an impact when those roles are compromised. So the roles that have online keys and require a lot of automation, they have less immediate impact when those roles are compromised so that there's time for the system to recover before anything really bad happens with these more vulnerable roles. And finally, Tough allows users to recover when a compromise does happen, either a compromise of a key or a compromise of any piece of the repository itself. And it does this in a few ways, primarily through hierarchical trust delegations. And the main goal of this hierarchical trust delegation is that if anything lower in this hierarchy is compromised, anything above it in this hierarchy is able to revoke those keys or replace them so that users no longer use them. And what this looks like in Tough is you start with a root role at the top, which is obviously the root of trust for the system, so it can be protected using all of those mechanisms we talked about, threshold signatures, and keys stored in more secure locations because they don't need to be used as often. And then this root role delegates to the other roles in the Tough system, which includes that timestamp role that provides freshness, a snapshot role that provides consistency, and various targets roles that provide the integrity of the actual content. It also delegates to the root role itself to allow for some in-band key rotation of the root role so that even those root keys don't have to stick around forever. They can be replaced using this in-band rotation. So the Tough project has a bunch of different pieces, not just one thing. The Tough specification is one of the big things that we do, and this describes the framework, including all those things I talked about, with more specific metadata formats and workflows that explain how these things work in practice. Tough also includes these Tough augmentation proposals, which are a process for proposing bigger changes to the specification or new features that we want to add. And finally, we have a reference implementation of Tough, which is written in Python and shows how this specification can be used in practice, what it looks like in the code. And we always aim to have the reference implementation in line with the current version of the specification so we can see how all these features work in practice. And we also make sure that any tabs can be implemented in the reference implementation before they end up back in the specification so we can work out all those bugs that happen when things are implemented in practice. In addition to the core pieces of the Tough project, there are also many different deployments and adoptions of Tough. These include adoptions that directly use the Tough specification, as well as adaptions that use pieces of the Tough specification but are adapted for slightly different threat models or slightly different systems. In addition, there's some work in progress, adoptions and adoptions, as well as obtain, which is a derivation of Tough for automobiles, which allows for repository controlled, repository directed updates, sorry. And this is used in a variety of automobiles as well as in some IoT systems that require that kind of repository direction of updates rather than the user asking for the packages that they want. So that's where the Tough project is. And so I'm going to talk a bit now about some of the new changes to Tough, some of the things that we're working on, and some of the kind of the new pieces. And I'm going to go into more detail about various of these. This is just kind of a quick overview. So some of the things we're working on is clarifying the Tough documentation and the specification to make sure that all this documentation is clear and that new users coming into this ecosystem can understand what's going on with the Tough specification, how it can be used in their system. We've also been collaborating with the Notary V2 project in order to facilitate uploading Tough metadata directly to registries. And I'm going to go into a lot more detail about that in a minute. That's one of our big projects. In addition, we have a couple of different collaborations with the Sigstore project, both integrating Folcio into Tough using that TAP process to improve developer key management. Again, I'll have more details in a minute. And in addition, using Tough as the root of trust in the Sigstore project. So it's kind of a multi-directional integration. We're also working on an ongoing integration of Tough into PyPI, which is the Python Packaging Index, which is the repository used by PIP and various other Python package installers. We're also working on a refactor of the reference implementation in order to approve readability and modularity so that other implementations looking to the reference implementation for guidance can have kind of a clear idea of which pieces of the reference implementation reference which pieces of the spec. And finally, we are working with members of the Intoder project and others on a new signature wrapper for Tough. This thing called Dizzy, or the Dead Simple Signing Envelope, which improves the assigning wrapper for Tough and removes toughs kind of reliance on canonicalization, which has been kind of a known issue with this spec. And so this is us working to improve that. Talk too long, this slide's way dark. So I'm going to go a bit into detail about some of these things. So first of all, this is the integration of the Sigstore's FullSeer project into Tough. So Tough today requires that for end-to-end developer signing, that developers manage and keep safe a private key that they then use to sign metadata and upload it, etc. And the idea of this tap and this project is to make this a lot easier so that developers don't have to keep this key safe over time because we've heard feedback that for many developers, this is like one of the biggest barriers to entry. And so FullSeer does this through the use of short-lived certificates that don't need to be saved over time, and they're backed by OICD systems, so credentials that the developers already maintain for things like email, GitHub, or anything else that they already have. And so what happens here is that Tough delegates instead of to a public key, it delegates to a FullSeer identity, and then the verification happens using the FullSeer process backed by OICD. And there's more details. I've brought a link on this slide, but the tap is available on GitHub. In general, there's a lot of links included in these slides, and they are available online if anyone wants to follow any of these links for more details, just as a quick aside. So the next kind of thing I wanted to cover is the work that the Tough project's been doing with Notary V2. So Notary, as some of you may know, is the tool behind Docker Content Trust, and it's an implementation of Tough for registries. And the idea of the Notary V2 effort is to improve the usability of Notary so that it can be used in practice. And so this has been a bit of a redesign and rethink of how we want to do this whole project. And so we've separated it into a lot of different sub-projects involving various different aspects, including how we're uploading things to registries and various other pieces. There's actually a talk later today, if you want more details about the overall project, the part I've been focusing on and the Tough project's been working on more generally is this Tough Notary sub-project of Notary V2, which really focuses on storing the Tough metadata on registries, and including some additions to the Tough specification and some adaptions for the specific project to allow for scalability of snapshot metadata, client-side selection of targets metadata to allow for less trust in the registry, and a couple of minor changes to allow for assigning digests in the registry space. And here's a quick diagram of the current design for this Tough Notary work that involves, in order to allow for using Tough metadata across multiple different repositories on one registry or on many registries, this design separates out the Tough repository from the content itself. And in order to, you know, and then the the targets metadata then delegates to the repository, which then contains the actual signatures on the digests. So we have a lot of ongoing integrations of Tough into various different projects. The PIPI integration, which I mentioned earlier, we are almost done with the part one of this implementation, which involves the registry signing of images, and then part two involves developer signing. So just kind of extending the process back one step at a time. So there's also an integration into Condor Forge and Bomba. And there's a very exciting, there's a new implementation of Tough being written in PHP for use in Drupal and typo3. So there's a great group of people working on that. In addition, there is some more caffeine on SIGSTOR, which I'm going to talk a bit about now. So in the SIGSTOR project, we've worked with the SIGTRA project in order to back both the RECOR transparency log and the full COCA with the Tough route of trust. So this means that it allows for both recovery of these roles if there's a compromise, and it allows for users to get the public keys for these roles using this Tough metadata backing it. So we have a lot of different implementations of Tough. And so here's a couple of quick updates about the different implementations that are going on. It's kind of a quick overview if you're interested in getting involved in any of these. So as I mentioned before, the Python Tough reference implementation is undergoing a refactor. The refactor of the client side of the system is almost complete. And we're looking at getting started on the repository side of this refactor to kind of use this new metadata API that we created to make these relationships more clear. In Go Tough, we've been working towards compliance with 1.0 of the Tough specification, including adding things like delegations and some of the other somewhat newer features of the specification that hadn't made it into this implementation in the past. Uptane, which is that adaption of Tough for automotive systems, had a 1.2 release of the standard this summer. And we're working towards a 2.0 release in the next few months. And this includes some interesting new pieces, including some kind of guidance about how Uptane can be used with broader supply chain security techniques, and a little bit of discussion about aftermarket over-the-air updates and how these can be used in the Uptane system. Google's Fuchsia implementation of Tough has been shipped on NextGen Nest hubs, which we believe is the first use of Tough in real-life IoT devices, which is pretty exciting. And in addition, as I mentioned, the PHP Tough is having its initial implementation. Lots of great folks working on that. A few implementations also didn't make the list. They're just still ongoing, including the REST Tough implementation and an implementation called Tough, T-O-U-G-H, which is also in REST. So finally, all of this is open-source software, or almost all of it is open-source software, and we would love any participation in this project. And so this includes both participation in the implementations and integrations of Tough. So if you have a favorite programming language, you can work on either the existing implementation in that language, or you can make a new one. And in addition, if there's any projects interested in using Tough to secure software distribution or updating, we would love to chat. We encourage contributions directly back to the specification. If there's anything that's unclear, anything that doesn't make sense on a first read, that's great feedback for us to hear, so that we can continue to improve the specification. And of course, if there's any new feature that's not currently included in Tough, feel free to submit a tap and we can discuss how and whether we can make that happen. And feel free to chat with us. So we have a mailing list, again linked from these slides, also available on the CNCF Slack. We have, I think we have three different channels there, an overall Tough channel, so for general questions, anything about the specification, and then specific channels for development of Go Tough and Python Tough. And of course, we're also on GitHub. All this is open-source, feel free to take a look around. And I don't think I concluded a link to the rendered version of the specification here, but that's also a great way to get involved, just to read through that, let us know about that. And I want to conclude with a thank you to all of the wonderful Tough maintainers that make all this work possible. And also to the maintainers and contributors of all of the subprojects, implementations, everyone else who works with us. Lots of great people, they didn't actually fit all on one slide, so thank you to everyone. And yes, please let me know if you have any questions. I'm available on all of these mediums, or right now I think we have a few minutes left, so let me know. All right, maybe to give everybody in the room a chance, we've got a question online. Cosine allows the uploading of signatures to registries as OCI manifests. Does this conflict with what is being proposed with Tough and Node-Review 2? I wouldn't say it conflicts. I think that they're both working in like a similar space. I think that with slightly different models and slightly different uses of the registries. So I think they're similar, but different is what I would say. Got it. All right, so you talked about the Fulgio Project integration as a root of trust. Has there any been, sorry, has there been any discussions regarding potentially using Spire or Spiffy as an implementation of a root of trust? Yes, we don't have any official caps about that, but that's definitely something that we talk about. So Tough assumes that you start with the keys for the root metadata on you get it somehow. And one of the things we do talk about is some people do trust on first use, other kinds of things, especially in the container space where you have ephemeral clients, things like that. Something like Spiffy and Spire is a really great way to distribute those initial root keys to then build up the trust in the system. So yeah, definitely something that we talk about. And that's a great thing to mention. Yeah, there's someone there. Is there any maybe plans on maybe using Tough to sign Git commits or anything like that? I don't know that we have any ongoing work there. I think there's other projects, including I think in Hodo and others that work more on the sorry, the code side of, you know, a part of the software supply chain. I think there's definitely ideas from Tough that could work there as well. We just haven't, you know, not specifically. Any other questions? Virtually or otherwise? Great. Thanks once again. All right. Yes, thank you, everyone.