 Okay. Hello everyone. My name is Marcos Cedro. Again, I'm a software engineer at HPE and also an inspired contributor since a couple of years. And today I'd like to share with you some work that we have been doing with some folks at HPE, Adriana Cardoso and Dorian Lambeck around using DevIDs and TPMs for Spire Note Attestation. We base our work in two important industry standards. The first one is the I2P standard for local and metropolitan area networks to secure device identity. This document, which was published a couple of years ago, defined the concept of DevID. Probably some of you are already familiar with this concept, but in case you are not, a DevID is essentially a cryptographic identity in the form of an expect online certificate with certain properties and protocols that make it suitable for device identification. The standard defines two kinds of DevIDs. A DevID can be an IDevID, which is the initial device identity that is created by the manufacturer at manufacturing time. And then we have the LDevID, which is the local identifier that is created by the administrator. And the other important document is the TCG TPM 2.0 keys for device identity and attestation. This document was released only a couple of months ago by the TCG, the Trusted Computing Group. This group is the same that defined the TPM specification. And this opportunity they are releasing this document when they are bringing us some recommendations for using DevIDs with TPMs. So essentially these recommendations are around how the TPM must be provisioned, like which kind of keys should be used, in which here it is in the TPM, these LDevIDs and IDevIDs must be placed. Another security and privacy considerations. So based on all this information and some previous work done by the community, we came up with this proposal. This is a diagram of the proposal of attestor. It is very similar to the X509 rule of possession attestor. But the main difference is that the signing operation instead of being done in the agent itself, it is done in the TPM, which is isolated. So the attestation workflow is the following. In the first step, the agent loads the DevID credentials, the certificate plus the scripted by the key. The encrypted key is loaded into the TPM. So now this TPM is ready to perform signing operations. And the DevID certificate is sent to the server side of the attestor. Validate this certificate using a configured CI bundle. If the validation succeeds, the server issues a challenge to the agent. This is an M1 that needs to be signed. So the agent asks the TPM to sign this payload, the TPM signs it and sends it back to the agent. And the agent sends the payload signed to the server, which finally verifies the signature using the DevID. And if it is successful, the attestation is confirmed. So this is in a few words how this attestor works. There's a lot more going on. If you are interested in this work here, you can see that the public did have issues where all this is being actively discussed. So we are happy to hear any comments or feedback about it. And now I will hand it to Adyani, who's going to run a live demo. I think it's now. Sorry, let me share here. Okay. Hello, everyone. So, okay, so as Marcus presented, our plugin is similar to the X509 pop and attestor, but leverage the DevID based on the TCG draft just published where the private keys protected by the TPM. So here I'm connected to a physical server with a TPM 2.0 and we already have a DevID provision here. We'll see the example later. So let's take a look on the plugin configuration here. So here in the server side, we have our node attestor plugin. We are calling it TPM 2.0 and we just need to configure the CA bundle path. This is the CA that signed the DevID certificate. Now, let's check the agent side. So here is our plugin. And we must configure where the DevID certificate private and public keys are. So as Marcus mentioned, the private blob is encrypted. So and the key can only be used once it's loaded in the same TPM in which it was created. So after node attestation, when the agent proves the possession of the private key that is rooted in the CA bundle, we extract information from the DevID certificate to create the node selectors. So let's now see an example of a DevID certificate. So this certificate we are creating using an internal provisioning tool that we have been working on that is following the spec, the TCG spec. And here we can see that we have in the subject information about the device like the platform serial number. We also have information in the in the extensions. We recommend the use of digital signature only for the key usage. This is also defined some OIDs that must be present like this one. That means that the issuer has validated the DevID residency. So in the during the provisioning team means the issuer has checked that all the keys reside on the same TPM of a well known vendor. The TCG draft is under review. So this OID has moved to the certificate policy field. So we need to update our provisioning tool later. TCG also specifies that the subject alternative name may contain information about the to identify the TPM. So as the TCG OIDs, these data structures in use here are not recognized by the OpenSSL tool yet, but it's not an error. It's just the visualization. Okay, so this is the example of the DevID that we are using. Now let's see it's working. So here on the top, I will start the spy server. And let's just check there is no attested agent. Okay. And now let's run here on the top on the bottom, the spy agent to check the node attestation. So here you can see the node attestation successful. Let's see now the selectors that we are creating. So here you can see that now we have one attested agent that used our plugin. And as similar to the X509 pop node attest, we are using the fingerprint for the SPFID and also as one selector. We extract the information from the certificate. So you can see here the certificate serial number. Each field value in the subject field and also in the issue field. So for each OID you have one selector. And if there is a well-known name also have this as a selector. So to help when creating the registration entries, we can think about extracting more information from the certificate like those information in the subject alternative name. For example, the IP address. And one discussion that has been ongoing in the community is to also add the PCR values as selectors. So this will require more change, but this is under discussion. So this completes our demo. This work is in progress. So we appreciate your feedback on this proposal. We are in the process to open source the plugin and the provisioning tool to help on the discussions. So thank you. Let's see if we have questions. Thank you. I think we did see a couple of questions. So Adrian, if you can answer, can you link the OID in the client certificate? This one. Let's go back. Show that ID. So here we have for each in the subject for each value we have one selector. So the code is genetic, right? So we just parse the values and create one select for each value here. I think Zach has a bunch of questions. I don't know Zach, if I unmute yourself. I don't see anything anyone else asking questions. There was an extension that open SSL doesn't understand. Yes. More about the what object identifier that is. That's defined by the TCGO ID, but open SSL does not recognize that. So for this one, and it was moved for to another field, the certificate policy. So I don't know if that's only adding in the dictionary in the open SSL to be able to read and present the well known name, right? But so far the open SSL does not recognize that. I guess I misunderstood. I was looking at the binary subject alt name too. Oh, here is the data structures. So what determines that data structure? The TCG draft spec defines what structures that must be used to represent the TPM information to identify the TPM. So this is, I didn't enter into details because there are so many difference. And let's say for the ID that is a must field for the local dev ID, there is a should field, let's say information. And since we don't have any platform with ID is available yet. This tool that we are working on following the spec is creating ID and we are using as a local dev ID in our plugin just for testing. Right. So, but these are these the data structures in the TCG spec that defines which structures must be used here. Okay, it's harder model. There is a name, the hardware model and the hardware type. These are these are fields is just open SSL isn't translating. Yes, yes, that's that's not on their horses just because we can it can pass it presented the well known name let's say just a miracle. It looks like somebody linked to the TCG. Okay, thank you. You're welcome. And the set my set my follow up or sort of unrelated question is like, from my understanding most manufacturers just kind of give you the CA, and you don't necessarily have like the manufacturer certificate. So how do you like tie this trust to like the manufacturer like, how do you build your, your database of serial numbers to bootstrap this trust. The idea is that we wish we must use the idea of this from the manufacturer. So, we don't have that yet, but soon manufacturers will be start shipping with this idea of ID. And then we must have the CA to verify that. And then we should have the local provision to create the all dev IDs based on the initial attestation keys that will be provided by the manufacturer. And the value of this is it's the hood of trust that comes from the manufacturers. Yeah. So just for testing that we are using like this way creating not in the manufacturer right because you don't have that yet available. Got it. Thank you. Great. Thank you. I just want to say kudos you're relatively new to the projects but you've you've entered with the bang, and you've ramped up in a relatively short time and are driving something that is quite a meaningful contribution alongside others in the team. So kudos to you and welcome to the community. Thank you. Great demo. Thanks.