 All right, I think we'll go ahead and get started. So first of all. Yeah, hi everyone. My name is Marina, I'm a PhD candidate at NYU and a maintainer of The Tough Project. Yeah, and I'm Justin Capilos. I'm a professor at NYU, Marina's PhD advisor. So first of all, since I'm a professor, I'm gonna start off with a pop quiz. So what do all of these organizations have in common? They're all major tech companies. Is it mine? Is it hers? Is it over my hair? I'm sorry. It's not going away. It's not my hair. Okay, well I'm gonna try this for a minute. And Eric, who's a graduate from the New York area is gonna figure out what the heck he's going on with the sound. So what do these organizations have in common? These are major tech companies. They have good security teams. They spend a lot of emphasis on this. Well, they all also have had their users attacked via issues with software updates. So if these companies can have their name on this list, then it should make you think your company can too. And we could put many, many more up here. So the thing that we're worried about in The Tough Project, the threat we're worried about is for attackers who can compromise a repository and do other attacks like this. So we assume that attackers can perform man in the middle attacks on the network, that an attacker can compromise keys that might be used to sign updates. And an attacker can compromise the repository or server itself and anything stored on that server. So if you have things inside of an HSM or something like that, that will not necessarily save you. In fact, it will likely not save you as some of the companies on the previous slides have found out. So ways that people have tried to solve this is they've tried to solve it with, hey, we're just gonna use TLS and so on, and put things on the server. And if you connect to our server, then you must be good. And our server must be, is never gonna get hacked or whatever. But the problem is that it doesn't say anything that what the server is giving you is actually accurate or correct packages. And your server now becomes a single point of failure. And so when the server, it gets, that you're using as a repository gets compromised, then all of your users are in a world of hurt. So that's how roughly, half to two thirds of the companies on that list got their names on there was using this as a security design. And the other way to do it was that they would just go and just sign something. They would have a key that they might keep in like an HSM, like is your IoT hub or something like this and sign an update package with this key. And this key can often be in like your build, farm, it can be somewhere like that. And your updater would ship with this, with the corresponding public key. And the client would need to trust this key. And this key would get used repeatedly. So it has to be online because it's being used to sign things. And so an attacker might not be able to take your key off of the server and take it back to their hacker basement and do their evil hacker things with it, but they might upload their malicious software onto your repository and sign it on there with the key in your HSM, right? So it's effectively the same thing whether they physically have, whether they actually control the key itself or they can just use it to sign things. So these are bad. Okay, so I did a bunch of work on things related to this and related to package manager attacks back in 2009. And the folks at Tor read some papers that I wrote about this talking about the right way to do things and pointing out all these problems. And they said, hey, can you help us fix it? And actually several people from the Tor project came and visited me at my lab and spent a couple of days with me working on a design. And at first they were like, the security's not that hard for this. How hard can it be? And so I walked them through a long series of things they had to worry about. And as they added more and more complexity and we discussed this, they went away and said, okay, now I think we have a handle on this. And they said, we have this thing called Tandy, which is a software updater for Tor. And it does all these great things. And before we go live with it, could you take a look at it and make sure that it's okay? And I took a look and I found eight serious security problems in their design. And this was a huge wake-up call for me because these are like among the smartest security people in the world who are looking at this problem and reasoning about it. And so building your own secure software updater is absolutely not trivial. It's a very hard problem, okay? And the solution to this isn't to say, like, trust me, I'm smart. It's like, let's get a group of people together to actually think really hard about this problem, spend a lot of time doing open design, get a lot of review, and build something out there that can resist a lot of these problems and attacks. So that led us to develop Tuff where this is a compromise resilient, effectively like a library or framework or mechanism you use to do updates and distribute and do your updates and things like this in a secure way. And it assumes that repositories, keys, and developer accounts can all be compromised. And the goal of Tuff is to reduce the impact of a compromise so that if you have things that do get hacked, the damage that the attacker can do is extraordinarily minimal. And I'm gonna talk some examples of that so you understand. And also, and this is really fundamental, is to be able to securely recover from a compromise. If you've used any of, you know, certificate revocation lists or online certificate status protocol, you've done any of that or you've done anything with like PGP key revocation, trust revocation, stuff like this, you realize these systems are really messy and really difficult. And, you know, it was definitely something added after the fact onto an existing system. And Tuff, we had this as a design goal from the very beginning. And so people are actually amazed how well and seamlessly revocation works in our system because it was such a first-class concern from the very beginning. Okay. So Tuff is based on a few different principles and I'm just gonna talk through them here so you get some understanding of the kinds of things we use to build it. One is, and I'll go through each one in a little bit of detail. So the first is responsibility separation. And this is an idea that you can have different roles that do different things in a system. So if you're familiar with role-based access control as you probably are from all the many systems that use them, you know this concept. So for instance, a key that might be trusted to say, this is a valid version of package X is a different key that might be trusted to say, there has been a new valid version of package X in the last 10 minutes, right? And you'll see in a moment about why that matters. Another thing you can do is you can delegate trust that you get in the system. So if Alice is responsible for the Foo project, Alice, you know, and the Foo project builds different versions, Alice can let Bob and Charlie decide to build possibly all those versions or some subset. In this example, Bob can only build Foo alpha projects because that's what was delegated to him. So Bob can go ahead and release those and they're trusted, but if Bob tries to release a Foo.prod project, a version of that package, then it will not be trusted by any user in the system. Also, Tuff uses a principle to minimize the individual key and roll risk so that keys that need to be used frequently are, sorry, so let me explain this formula here a second. You know, I'm a professor, I have to have at least one formula on my slides. So the expected damage is roughly equal to the probability of the thing happening times the impact, okay? And we wanna expect a damage to be very low. So it means that one of these two terms has to be very low, right? So the way we do that is if you have a high impact role, like a role that serves as a root of trust, you'll have highly secure keys where you might have a bunch of keys that are actually physically stored as UB keys in safety deposit boxes that are distributed amongst administrators, okay? And for keys that need to be used frequently, then you need to make the impact of those very low. So for instance, a key that might actually live on your repository, the impact you would have from that being compromised would be something like being able to say to somebody there hasn't been an update in the last 10 minutes when in fact there has been an update in the last 10 minutes. And so you can see that that impact is not particularly severe. Tuff also allows you to do multi-signature trust as I kind of alluded to with my other example. So you can say, there are seven people in a certain role and four of them have to come together to do something or whatever. You can say a person from the QA team and two of our developers have to approve a release before it goes out. You can make those kinds of statements very easily. And Tuff also, as I mentioned before, really focuses on revocation. So there's explicit revocation where you can make a statement to say this key or this like software release or this image or whatever is no longer trusted, which is very simple and natural to do in Tuff. And you can also make statements about the timeliness of information. So you can say this thing expires after this amount of time. So you have both explicit ways to revoke trust, independent of time, and you have implicit ways to say this should only be considered for the next six months or something. And we've had a lot of different security audits with them, with Tuff that are all available here. We published a lot of peer review papers that have also had a lot of security scrutiny. We have many more audits and things like this that we can't talk about because they're not necessarily public for some of the less widely used implementations. And in fact, we just yesterday are able to publicly release information about the Python Tuff implementation, which is our reference implementation, which VMware, especially Joshua Locke and everyone on his team did such an amazing job with hardening. And we are very proud of how our audit turned out. We encourage you to go read the blog post because yeah, we're very happy with it. So if you do think, you know, hey, I think I can do something better than what these guys and the tour guys and all the folks from all the big companies that have worked with us and all the security auditors have done, feel free to make it public or send it to us and ask us to look at it because we think we've seen a lot of, designed in this space that aren't quite where they need to be with security and we don't want more of them. And with that, I'll hand it over to Marina. I think he just had to turn the mic on. You should be good. Okay, okay, cool. Hi everyone. So I'm gonna talk a bit about the current state, the Tuff project, and give you some updates about. Yeah, let's give him a second. Thanks. Okay, great. It's gonna be a little better. So yeah, and some updates about up and coming things and recent status updates. So yeah, here's the current Tuff status. We are one of the 12 projects to have achieved the OpenSSF Gold Best Practices badge, which is the highest badge that they offer. There's an automotive variant of Tuff called Uptane, which has been standardized initially in IEEE as part of their ISTO group. And now it's under the auspices of the JDF. And so that's still on this ongoing issues there to get that going. And finally, the Tuff project itself is a graduated CNCF project, as many of you know. It was in fact one of the first specification and the first security project to achieve graduation in the CNCF, which we're very proud of. There are a lot of different implementations of the Tuff specification. I'll highlight a few of them here. Python Tuff is our reference implementation, which we use for some experimentation with new features in the specification. It's also used in production by various folks and it's maintained by the groups here, as well as additional contributors who aren't named on the slide. And with all of these implementations, we have lots of amazing contributors. Go Tuff also a very popular implementation, some similar overlap, two implementations in Rust, maintained by different groups for different purposes, a new PHP implementation, and then an actualizer, which is a C++ implementation used specifically for Uptane in the embedded space. So that one is maintained by Horizon. So yeah, five different languages, lots of different work going on in this space. And all these implementations have been deployed in a variety of different places. So as we're at CNCF, Cloud Native Conference, we'll talk about some of our cloud deployments, which are the highlighted here, as well as we have various deployments in the automotive and IRT space, especially the Uptane variant, but also Tuff itself in this space. And some other kind of exciting ones, including a variant of Tuff called the Archive Framework, which a variety of governments use to protect laws and court rulings and keep them in a verifiable way. So here's some other updates about our different implementations. As Justin mentioned, the Python Tuff project had recently had a really big refactor, where we created this whole new metadata API abstraction to make the code a lot more maintainable, a lot more readable, and hopefully a better reference implementation for other folks who want to use it as such. And there's ongoing work on a repository tool that then uses that new metadata API, but the client work is all done there. Go Tuff is some exciting new maintainers and new users in that space. Some great new work done, especially in delegation support, and lots of other ongoing work with key formats and other changes to really keep that progressing. So now I'm gonna talk a little bit about other updates to the Tuff specification itself. And the way changes happen to the Tuff specification, anything larger than a typo change goes through this Tuff process, the Tuff augmentation proposal process. And the idea here is that anyone can submit a proposal to change or add something to the Tuff specification, and we go through a whole process to make sure that the security properties of Tuff will be maintained, that this is a good idea that has real-world use cases that will be helpful for the specification. So a couple of these that have some recent updates. We have Tuff 15, which is, it's the title is succinct hash bin delegations. The idea here is that Tuff has this format for doing delegations to a huge group of targets in this succinct format. And this even further reduces the metadata duplication to reduce the metadata overhead of using this feature in Tuff. And an implementation of this Tuff was recently merged into Python Tuff, and we're really excited about the use for really large repository implementations that can take advantage of this. And as I mentioned here, it reduces the Tuff metadata overhead for hash bin delegations by a factor of eight, which is very cool. Tuff 14 is another very exciting one. This Tuff is all about managing Tuff versions and managing breaking changes to the Tuff specification. And what's exciting here is a little bit of the Tuff itself, but really the opportunities that this Tuff opens for other breaking changes to the specification and kind of an upcoming 2.0 release to be seen very soon. And so yeah, the idea of Tuff 14 is that the repositories and clients that use Tuff can coordinate specification version changes, even if a client is using multiple different Tuff repositories or a repository has different Tuff clients to make sure that this can all be coordinated. And we have a proof of concept of this in Python Tuff and in the Tuff itself is pretty much ready. We have Tuff 17, so final one I'll talk about, which is a change to the signature wrapper format in Tuff. This is kind of step one of this process of getting rid of the need for canonical JSON in the Tuff format. Currently, the way Tuff does signatures on different metadata files is it first has to canonicalize these into JSONs that you can have bit to bit matching between different pieces for verification. And the idea of this Tuff is that we can eliminate the need for that canonicalization using other things. And so this is pretty exciting as well. And this really reduces the chance of a lot of metadata parsing bugs. There's a whole class of attacks that are known on parsing JSON. And so this is a pretty exciting one. I'll talk a little bit too about kind of where Tuff fits into this ecosystem and other related projects. I think one I'll highlight here is the SIGSTER project, which we are also active members of, but if you're just gonna compare what we do, what they do, how we're hoping to collaborate more. So Tuff, especially historically, has really had a focus on developers managing keys. And a lot of the different properties of Tuff to discourage key sharing and all of these things require lots of different keys properly managed in the system. And SIGSTER has a really great way to have SIGSTER itself manage the keys to improve usability in that way. And so I think the short version of this is that I think Tuff has a lot more security guarantees and SIGSTER has a bigger focus on kind of the usability first and then also the security pieces as well. As we mentioned earlier, revocation in Tuff is a central property. And in SIGSTER, there's a much bigger focus on auditability and detection of attacks rather than the revocation and prevention pieces. And Tuff has been used in production for over 10 years in various different systems. But of course, there's also like integrations between these projects. I think both projects have good ideas, right? And so we have SIGSTER project actually uses Tuff as its root of trust. So Tuff is used in SIGSTER to distribute the root keys for RECOR and Fulcio. And we have a lot more ideas about how to do more across integration, including using the SIGSTER key management in Tuff to improve usability for developers and adding more support for Tuff metadata files in SIGSTER. So yeah, so so far in this talk, we've really talked about this last mile of the software supply chain. So Tuff and SIGSTER and all these pieces really focus on, okay, we have a lot of packages in some kind of repository or registry. How do we securely get these to a user? But of course, the software supply chain is much bigger than just that. Here's an example of it of a fixed supply chain that involves various dependencies, various different processes. And we have integrations with Intodo and other projects in order to secure other links in the supply chain. And so some of the additional features you can get here is securing all those different links in that supply chain. Intodo is another CNCF project. We call it our SIGSTER project. And it is widely used in other projects in the CNCF and elsewhere. There's a couple here. And Tuff and Intodo have a number of integrations. And it was, I think, one of the first integrations in the cloud-native space. We have a couple of really good integrations of these two technologies. And they really complement each other because Tuff can provide the root of trust and the key management and expiry and all these properties we've talked about. And in addition to actually distributing artifacts, it can be used to distribute other metadata like the Intodo layouts and attestations. So not only so that you can, you know, you have all one system that distributes all of these different pieces to secure your whole supply chain. The Tuff project also is always looking to the future. I think one of the advantages of coming to this project from a research lab is that we're always looking at the next things. What else is out there? And so, of course, a couple of technologies you may have heard of, blockchain, post-quantum crypto. We have some pilot support for quantum crypto support in the secure systems lib, which is the cryptographic library that both Tuff and Intodo use. So we're hoping to get some of that, especially in the automotive variants, which are really long-term integrations of Tuff. Yeah, other ongoing integrations. I think the key line in Intodo, some more integrations going on, and we're really into experimentation with future technology to make sure that we're always looking to future things that are happening. And yeah, so yeah, but these are not yet part of the specification. I think they'll have to go through the whole type approval process. We want to make sure that technologies are mature before we actually require use for everybody, but we are looking ahead to things like post-quantum. And finally, we want to encourage everybody here to contribute to Tuff. We, I think we're a very welcoming community. We love new people. You can talk to us on Slack. We have a tough channel, as well as various other channels for individual implementations on the CNCF Slack. We have a mailing list, which is mostly quiet, but it's definitely a great place to have more in-depth conversations. A website which has links to various previous talks, papers on the project, and lots of other information. And I think the best way to get involved really is GitHub. Everything we do is open source, and so easy way to get involved is to look at our open issues, on the specification, on the tabs repository, and on all of our implementations. I link to a bunch of the implementations here. Many of these are used in production. Some of them are up and coming. Lots of great places to get involved. So yeah, thank you. And hopefully, let us know if you have any questions, or anything else you'd like us to talk about Tuff. You can shout it when we do it. So the question is, are you involved in IETF for the standards bodies? No, no. Okay, so the Uptane project, I think is the biggest standardized project in Uptane. It is a, wait, it wasn't, wait a second. Yeah, so there's an IEEE is the standard, and we're under the JDF now, where there's like a path to OSI and stuff like this. And the reason why we went that way with Uptane is because the automakers, our adopters, had that as like a question, like, hey, could you do this? And we looked into it and said, sure, no problem. We'd be very happy to do the same with Tuff. We were actually have been approached a couple of times to push it through processes with different organizations. And we kind of, one of the really important things to us is that we still maintain control of the spec and control of the way it gets edited and control of what happens over it. So we may do that in the future if there's a real desire for it, but it hasn't been a pressing need yet. So yeah, happy to take any other questions anybody has. Okay, well thank you all for coming. I won't stop you from going out and having a fun Thursday night. See everybody later. See you around at the conference.