 Okay, yeah, sorry for, thank you for solving, yeah. Well, what I will share here today, it's about the Archivista's story in Polish and using tough to build trust. Maybe nobody's familiar with many of those words here, but I will try to give a little introduction before we start. So my name is Cairo, I work at TestifySec. I'm an open source engineer. I'm an author of the repository set for tough. It's one service that provides the tough repository. I'm also maintaining the total Archivista and I'm active in the tough community. And I will advise for everyone if there is more advanced and tough questions, there are many people there that can answer that. But that's, okay, first, I just prepared this quick introduction here. Daintoto is an attestation framework and we'll talk about witness here. Witness is using the Daintoto framework and this is an CLI that allows you to generate attestations and also verify these attestations against polices. So what I will demo here, we use witness to generate an attestation and validate the polis. Archivista, it's a graph and this storage serves for total attestations. It means that if you generate attestations, you can store all the attestations in Archivista. You have GraphQL to make queries so you can retrieve the attestations that you want to verify. Excuse me. And tough is a framework to secure the distribution of artifacts and doesn't matter which, it's your artifact actually. Of course, we use this a lot for software but any kind of document imagine what you need, you can use. And in that demo, I will be using also our stuff because I don't need to build in Archivista all the tough repositories so I can just integrate it with our stuff. Okay, what I will demo here will be basically this confusing diagram. Of course, I will divide it in parts to make more understandable. Yeah, what we'll show here is the process of witness generating an attestation and storing this attestation in Archivista. And this attestation will be available for queries for witness when they want to verify what is in below here. Of course, I will show also the policy generation and storing this policy in the Archivista. So what I need to also highlight here is that currently witness and Archivista can store an attestation but cannot store a policy. So what I will demo here is actually on a work in progress. It's a POC of Archivist is starting policy. Also currently Archivist doesn't support tough. So in that demo, it's also a work in progress that we will share. So securing the policy. And the reason why we want to secure the policy is we don't want an attacker that gives you a policy that will validate your attestation and say, oh, everything is okay. So we'll go through this demo now but as I said, let's divide it in parts and you can understand what is the work in progress here. First thing is like Archivist now has a database, the SQL that allows the GraphQL queries and also store the attestations in the S3 buckets. So it's compatible with, for example, you can use AWS S3 and store your attestations there. What is new here is the layer that we are adding RSTub. So RSTub also use the same, most of these components, the database in S3 and we will be signing every time that you add a policy, we will sign it and make it secure. So as I said, I would demo here the KMS layer, the S3 bucket and also the tough. And I would say that also there are Archivist and administration layer that is creating the tough metadata and signing it with the keys. So yeah, but I know that's very confusing talking about signing root metadata and tough. I don't know if how many people here are familiar with that but basically I want to describe one example that can understand more what I'm talking about. Imagine that you have the root metadata that's signed by HMS or UB keys or you can use Futures to store as well to sign it but you have also the target keys that signed the metadata where you store the policy and in that case we are using KMS. But why we have this definition of multiple keys for root and also the KMS key because you have the delegations in tough metadata that you have multiple tough metadata and you have root that delegate to targets where we store the policy in our scenario here. So then let's get an example why this is important. Imagine that you have a situation that you have an environment then you have one KMS key but for some reason the key axis was weak and the key ID one was a liquid. So that key was signing all your policies when you're storing the metadata. So tough allows you to do recover the situation I mean rotating this key. So you create a new version of the root metadata and all the administrators will sign it and when in that case we have one rule here that we require two signatures in that K in that new root metadata and when the second key is added. So this second version it's valid and all the clients in our scenario here all the witness client will use this second version to validate the target metadata that contains the policies. So then the question that most of I receive is like oh do we need to redistribute the new version of the root metadata version too? Actually this is the magic of tough you don't need to go to distribute because the first version can validate the signatures of the second version. So let's go for the demo demo. Well the first thing that I want to share is the deployment of course this is my computer and yeah this is a development environment but I want to just make like reference for a real deployment. So we have the SQL database, PostgreSQL we have a Radis that is used as a message queue for our stuff and here is one important component it's that local stack I'm used to simulate the AWS services so with local stack I'm using the KMS servers and also the S3 buckets so yeah. And we have Archivista that uses all these components and also the API. So you see running here it's my deployment I want to highlight some parts of this. It's first yeah this is my KMS key so local stack can simulate it very well and I have also my S3 yeah my S3 buckets should be some place here yeah. I have the bucket for the tough metadata and also the Archivista. So what I will share now it's a process that I mentioned before signing the root metadata so basically what I'm doing here is create the ceremony where everybody will give the keys and we can sign it. I need to do this because everything here is running dynamically so I will be quick I will not go in details that are not relevant for this demo here but yeah. So here's the where I want to share the I want to add the KMS key in that case I'm using the ACDSA the size is okay. It's okay the size yeah. All right so I will use the ALIS that I'm I added when I create the keys so I don't need to deal with the IDs. So it will retrieve my KMS key and I'm loading the root keys. As you remember I said that okay this will be the keys used by the Admin or Archivista let's say. The first one is Janice Joplin and the second one. So this interface that you are looking here is the RStuff CLI for creating the ceremony and creating the first trusted root. So and the second designer here is Jimi Hendrix let's say that he is using his HSM or his guitar I don't know. Well, well this is a validation that I don't go through because it's not relevant here for our demo. And the next step that I'm gonna do I will bootstrap it. I will say okay RStuff here's my trusted root create all the delegated roles where you want to store the policies and make it safe. Okay and it's finished. Okay it's everything work in progress. Bugs everywhere. So now I'm creating the tough, the secured tough that will be used by Archivista. So now let's go for more for the topic that I said let's say witness Archivista now what we will play around first. Let me get the Archivist witness. Okay. Yeah first thing I would generate an attestation. Okay what am I doing here in that comment? So I'm running a witness to generate an attestation that the step will be release. I'm using as a signer for this attestation on a KMS key. And the output of this will be the attestation that is a DC envelope sign it. And this is the comment that I'm running to let's say release this artifact. Okay. Imagine that this also could be as in your CICD that you are when you build your Docker image or your container image or you build your application is the moment that you are tracking everything all the steps that are doing all the parts of this step. So I generate an attestation. I will share what is an attestation but what do you see here is a DC envelope. But if I go through, if I can just open this attestation you will see that it's like logging or adding all the steps, all the hashes, all the output of the command, environment variables, everything it's collecting and this part the attestation. And this is a compatible in total attestation. So what I have also in with Witton is the ability to generate policies and validate it, right? So here's the policy that I wrote for these attestations. So this policy contains some regular policies that basically the regular policy can add verifications like for example, my build command was exactly this command to build this application or not. Was the exit code of my command that build was zero? So this policy can be stored in Archivista in the future, it's a work in progress. And every time that you generate an attestations and your clients want to download your artifact, they can validate if your attestations pass to your policy. So you check out the security of that. And what we are doing here, the layer, it's storing this policy also in the tough metadata to avoid any kind of attacking the middle. So what are you gonna do now? I will sign this policy. What I'm doing now in saying that I want to sign the policy that I wrote and I will generate the new signed DC envelope format. And I'm using the KMS key to sign it. So then I generated the signed policy. Okay, what is next? Next I want to store all these two components. Let's say that my CI CD every time that generate an attestation, automatically push it to my Archivista. And every time that my team define a policy to be used on the validation, I will also store it in my Archivista. So I will go back to the Archivista and I will store all those components. So the first thing that I will store is the attestation. And the second one that we store will be my policy. Okay, what I can share here very quickly, it's like you say, this is really low level, but yeah, it's going through my Archivista and also going through my tough metadata and just sign it by tough metadata. So what I want to do now is the next step that it's validate this policy against, sorry, these are the stations against my policy. So that would be, this is the step that I just shared. I'm uploading policy to my Archivista that can be retrieved by a witness when validating. So let's go to the validation. Sorry, I'm switching a lot of screens, but it's really last minute demo that I prepared. So okay, let's do the verify. I will first do the verify that we don't use Archivista to retrieve any policy. That's how you can do it now. So basically you pass your policy, you pass your attestation and the key, the Puppy key that can validate these signatures and the artifact. So basically in the artifact digest the SHA, of the artifact, it can start all the validations and verify. So if I do this, the attestation pass because there's nothing wrong, everything match to the policy that I wrote. So, and the second way that I can do this now, it's the demo, the prototype. You see that I'm removing a lot of information and just giving the root.json, that's the trusted root that I sign it and the artifact. What happens here, it will be, sorry, this flow, basically based on the artifact digest, it retrieves all the attestations that contains this digest. And from the attestation, it queries the graph query for the Archivista, all the policies that contain the subjects for the attestations. So then it looks all the policies that contain the same subject and retrieves this. Okay, let's go for this. And this will not work in propose. Yeah, it's not to work because right before this presentation here, I run the demo to check if everything was okay. And I changed the root metadata. You saw that I just generate a new root metadata. It shows that nobody can go to the witness and give invalid root metadata and it will not pass. So I will retrieve the trusted root metadata and what you can see now did pass because the trusted root allows the witness to retrieve the policy that I started because this policy is signed with the keys that I should have. So back to this, what happens here basically when you saw the error was that invalid root metadata was given to the witness and now in the witness that I'm demoing here, we have a tough client based on a go tough that checks the tough metadata and verify that there's a new version or not but validates if the current version is valid when it go to download the targets as well. So every time that I said that we can rotate the keys that are in the root metadata, always the previous versions can validate the next version. So from the one version, you could go for version nine without problem. And I'm using the root metadata to store more interesting information here. I go through this now. Yeah, so you saw that I reduce a lot the number of information that I give in that comment if you compare with the previous comment. It's because I'm using the root metadata as a sign of the information to store important information like what's my Archivista URL. So it means that you are even providing the where is my Archivista in a safe way because you are adding it in the tough metadata. It's a kind of SSL verification that we are doing. And to rotate this information, let's say your organization changed your Archivista URL. You just need to give it in the new version of the root metadata and it will be able to retrieve all the information. I'm using also the our stuff or tough metadata also stored in that part. So it's easy to end the safe to rotate information that is crucial for your clients to validate it. So next to what we want to do is create a policy approval. It means that every time that your team create a new policy, the other people that are, let's say, validating this policy or reviewing this policy, they need to sign the tough metadata as well using their UB keys or any kind of HSM or SIG store. So they will sign it and we say, okay, this policy valid. If nobody signs this policy, this policy will stay there, but it's not valid and the witnesses will not use them. So it allows, as I said, you can rotate it and you can create a set of people that are authors and approvers of this policy. And how we store in the tough metadata, I know that's a little bit confusing, but yeah, we have the policy store in the tough metadata that is sign it. You see the sign up part here, but we keep also the old versions of this policy. So if you need for a certain version of an artifact, validate against old policy, you'll be able to do this as well. And what is next? We need to improve this mapping policy to attestations. And I'm cleaning up this code to make it in upstream so people can just start trying it and give us early feedback for that. Yeah, that's it for the demo. Questions? Questions or any point that we want to discuss is welcome. Mostly for a software that doesn't matter which type of artifact this software is, once you can generate attestations, you can use this process. If you can generate an attestation for the secret generation, yes. If you can, yeah, maybe you need to write your custom attestator for this. By the way, we have in the second floor the booth of in total and tough. So if you wanna go there to understand more about those components separated or, yeah, because this is a work in progress, nothing is released yet. Just want to share with folks here. Okay, thank you.