 Hi, everyone, and thanks for joining in today. I'm Eugde Vallon. I'm a software engineer at ARM. And I will be presenting Parsec, the platformer solution for security, and also its involvement in the large errors community. So let's get started. First, let's see why Parsec. So the edge in between the cloud and the IoT endpoint is becoming a richer, compute-capable world. At the edge, you would want to execute richer workloads, for example, for machine learning or sensor data analysis. Similarly, then in the cloud, the edge is a multi-tenant environment where multiple applications could be accessing the same device. And similarly, then in the cloud, you would want in the edge to have access to the various cloud-native development tools. But very differently from the cloud, the threat landscape is totally different. You would have new threats in the edge than in the cloud. The platforms are also very diverse. And specifically, the route of trust that they have, so the hardware-backed security modules present on those platforms, can be very diverse. You could have trusted platform modules, hardware security modules, and secure elements. So there is a conflict there between, on one side, having applications that are highly secure, that store their keys in real hardware in those route of trust modules. And that's also easily deployed. And on the other side, this big landscape of different platforms and different hardware-backed security devices. So Parsec is made to solve that problem. Parsec provides a uniform compatibility layer across the diverse world of edge. Parsec makes the connection in between cloud-native applications that are written in any programming language and between the device that can be any platform on any architecture and working with any hardware. So they could be trusted platform modules, hardware security modules, trusted execution environment services, and other hardware-backed security modules. So Parsec is making these connections so that cloud-native development is possible at the edge. Secure development is possible at the edge. So let's see, on a conceptual view, Parsec API is rooted in platform security architecture PSA. And specifically, Parsec use the PSA Cryptography API, which is providing key storage and a lot of different cryptography operations like, for example, asymmetric signing, symmetric signing, and many more. Parsec is a service, a service that is available to clients in a rich OS. So it's a user-space daemon, which is not accessed through one specific language. Parsec has developed its own wire protocol, which is language agnostic. And on top of which, client libraries can be developed. So client libraries in a lot of different programming language that know how to communicate with the IPC protocol in a convenient way for developers. So that's accessing in a rich workload, the hardware-backed security modules is easy. So let's see in more detail what is the service architecture there. So the Parsec service is made around the front end and back end architecture. So on the front end, you have the listener, which is the component responsible for taking in the requests of all the clients on your system. So the listener knows the wire protocol and pass the request deeper in the service so that access control is performed in between the different tenants. And the requests are passed on the specific providers that needs to respond to the request. And the provider is the back end of the service. It is the part that has the hardware-specific knowledge on how to communicate with the root of trust. And on the left, on the other side of the IPC, there is the cloud-native application, which is using the Parsec client library to be totally platform-agnostic, and that will work on any platform. So anywhere that this application is deployed, anywhere that there is a Parsec service, it will work and will not need to be reconfigured. As it was previously, if this application wanted to use a TPM or HSM, it would have to change its API calls. But with Parsec, it doesn't have to. And I've talked about client libraries. There are client libraries, ergonomics, depending on what is the use case. So there is different layers. The first layer, the client library core, is for sophisticated use case with granular control. And that's a layer where all operations with all parameters are available. So that's the most complicated layer because one developer would have to set the specific parameters for each call. But there is a high level for specific use case, which where the client library makes the choices for you with a small defaulting or capability profiling, where parameters are already set, basically. And I'll show in an example layer, later what the client library core looks like for the rest clients. Multitenancy is obviously an important part of this. So Cloud native workload delivery at the edge is expected to be multitenant. Multiple applications will share access to the secure hardware on the platform. Each application needs a unique and persistent identity, which is assigned by a component that Parsec can trust. The Parsec service treats each API call according to the identity of the application that made a call, partition key stores, and brokers access to hardware based on the identity. The source of the identity depends on the deployment. It might be a container runtime manager, for example. A deploy system requires an identity provider, a separate component that assigns identities to applications, which has a true relationship with the Parsec service. Let's see how it works in practice. So in your typical system, you would have the Parsec service sitting on top of the hardware-backed security modules and applications making calls to the Parsec service. Separately from the Parsec service, there is the identity provider, which roles is to give to each application on your system their specific identity. This identity is given on their request to the Parsec service. So whenever an application wants to make a call to the Parsec service, for example, to generate a key pair or to use a key to encrypt some data, the application has to give its identity to the Parsec service. And the Parsec service with that identity will perform a key store partitioning so that one application cannot access the key of another one. But of course, Parsec needs to trust that identity and needs to verify it so that the authenticity of each of those identities is respected. So there needs to be a trust relationship in between Parsec and the identity provider. For example, one identity provider that we currently have in Parsec is using Unix user ID. So with that identity provider, the applications, when making calls to Parsec, give their UID to Parsec. And to verify it, Parsec uses a feature on Unix domain socket called peer credentials to make sure that the UID given in the request match the actual UID of the process which is on the other end of the Unix domain socket. And if they match, Parsec is sure that the application is indeed the one that it says it is and can use that UID as identity to partition the key store. Another identity that we use in Parsec is the specie ID. And using a spire as a specie implementation, for example, the application fetch their specie ID. And what they actually fetch is the JOTS SVID token using the specie workload API. They give this token to Parsec. And Parsec uses the workload API as well to verify it and make sure that this token is valid and uses the specie ID as the application identity to partition the key store. So this is two examples of authenticators, one coming from UID from the operating system and the other one coming from specie. But many more are possible. And more generally, in Parsec, there is a pluggable architecture where all the different parts can be changed. So other identity provider are perfectly possible, depending on the deployment of Parsec. So ultimately, to use Parsec, you need the client library written in the language that you want. And what we have currently, we have support for a REST client library. We have support for a GO client library, a C client library, which is made possible through Embed Crypto. And we also have a CLI tool to access Parsec. So each of those are ways for your workloads to access the Parsec service. And let's see how an actual example of the REST client library looks like. So as I told before, this is the core library level. So the layer where all the parameters are to be defined by the column. So not the easiest layer. But still, as you can see, all this code, which is around 25 lines, is enough to instantiate Parsec clients, generate a key pair, sign a hash, and export a public key. So actually, it's not that much. So if you focus on the four last lines, we actually do perform the actual codes where we create basic clients, which is the name of the REST client. We generate a key pair. And that is using the PSA Crypto as an API, as I told before. So when generating a key pair, you have to give key attributes. And in that case, we say that the key that we are going to generate is a ECC key pair. We give it its core family and the specific curve that it's going to use. And also we give a policy where we say that with this key, you will only be allowed to sign hash and nothing else. So you can't export it, for example. And you can only use an algorithm that we specify. And in this case, it's ECGSA with SHA256. Then on the other line, we sign a small text with it and this specific algorithm. And then we export the public key. So two other things to notice in that snippet of code is that the key names are referenced using UTF-8 strings. So as you can see, you can put emojis in it, which can be nice. And also to actually instantiate a client. So there is just one new method here. But what happens in the background is actually a very much more complicated than that is that when creating this client, this client will actually use the default Parsec provider and the default Parsec Authenticator on the system. And when I mean default, it's the default that has been set by the Parsec administrator when setting up Parsec on the system. So this code, these few lines of code, anywhere they are deployed, they will work. And they will work on the default provider and the default Authenticator that Parsec is working with. So if Parsec is deployed with a TPM, this will work with a TPM. And if Parsec is working with HSM, but this code does not have to change. And that's the big value proposition of Parsec. That's the cloud native way. So I've shown the Rust client. Let's see the exact same code, so the exact same operations, but using the Parsec tool, which is the CLI client. And in the exact same way here, we have comments to create a ECC key. We have another comment to sign. And then we export the public key here. And in the exact same way, this is using the default provider and the default Authenticator on the system. Of course, if Parsec is deployed on a system where there is both a TPM, an HSM, and a trusted service, it's possible to choose like in the code, the specific one that you want. But by default, and using the simple comments, it will use the default one, which is often the only one that Parsec is deployed with. So yeah, that was it for the Parsec part of the presentation. I also wanted to present what's our involvement in the larger Rust community. So what do we do for the Rust community? So as I told before, Parsec is heavily realized on the different route of trust, so on the different hardware backed security modules that we use. And instead of developing the code inside the Parsec code source, we decided to publish independent crates for each of them. So for example, for the TPM, we have a TSS ES API crates, which is a wrapper around the enhanced system API to communicate with TPMs. For HSM, we have the CryptoKick rate, which is a wrapper around the PKCS11 API. And for the trusted service provider, and that's used in Parsec as well, we have the PSA CryptoCrate, a wrapper around the PSA CryptoCAPI. And all of those crates are rebuilt in a similar way because they are, as in the all safe abstraction of the CAPIs. So they are really using Rust eJumps and Rust eGeometric codes to make sure that what is exported in Rust is always safe, the memory safe and thread safe, so that they are actually here, really nice to use. And even for someone that has no interest at all in Parsec and just wants to use the TPM HSM in Rust, those are really nice to do so. And many people are using them, yeah, totally independent from Parsec. So that's really great to see engagement from the committee just for those specific parts. So other than the crates that we ship, we also contributed to other Rust projects. So for Byangene, for example, we added support for dynamic loading in Byangene itself, so using the lib loading crates, so that Byangene is capable of generating a structure which creates a lib loading context. So that's for example, you can see here, and that's what we use in the crypto key syscrate is that it generates this pkcs11 structure in this specific case because it's been given the pkcs11 c API header file. And so that at runtime, we just have to give him the path of the dynamic library and it will automatically create the lib loading structure. So that's really useful for Rust abstraction over API and libraries that are meant to be loaded at runtime. We added the peer credential support for Unix domain sockets and that's currently available in nightly Rust with the peer cred method that is to be executed on the Unix stream. And that method actually returns the UID and the group ID of the process that is on the other side of the socket. And that's mainly what we use in the parsec autontigator to make sure, to check that the UID match the client that is calling parsec. And also we added a basic Jot SVID token API support in Rust.py and that's what we use in our specific base autontigator. So yeah, so that's it for this presentation. Thanks a lot for listening to it. You can check the code of parsec and the code of the different crates that are presented in the Parallax second GitHub organization. If you're interested in parsec, make sure to check out our book. It actually contains a quick start guide if you're running Linux on x86 to really get you started quickly and trying the CLI parsec tool quickly. We are on the CNCF Slack workspace on the parsec channel. If you have any questions at all, really feel free to chat with us and we have weekly community call as well on Tuesdays where you can also join and chat with us. So if you have any questions, I'll be really happy to answer. And yeah, otherwise, thanks a lot for listening to me today. Thanks.