 Okay, let's get it started. Thank you for attending this session. This is the last session for this meeting, so my name is Iris Dien. I'm coming from Intel, so my co-speaker Malini cannot be here today due to the travel issues, so I will cover the whole topic today. The sex to my college here also did a lot of contribution to this topic. So today, I will share something about Cloud HSM, and what's the challenge you might be fitting if you're using Cloud HSM, and how we can overcome these challenges using distributed HSM, and finally, I will show you some user cases that you can leverage it in your environment. So HSM or hardware security module, this is not very new technology. Actually, it has exist for a long time. So basically, you need a specific plugable hardware that you can store your credential information like private keys in this device, and also you can perform your crypto operations in this device. So you can see it also means you need some additional cost because you need a specific hardware and you also need to maintain it. So besides this, the security is coming more and more important today. You can see from this call right is cloud native security come. So also in the cloud environment, this also bring a lot of security requirement. So this is some report for the HSM market. So it says due to 2028, the HSM market will be reached to $2 billion. So it's a huge market. So as we said, a lot of our cloud has been onboarded to the cloud environment. So currently most of the major cloud service providers has already had their cloud HSM offering. So it means the cloud provider will host the HSM hardware in their cloud infrastructure. So for the customers or for the end-users, this bring a lot of benefits. For example, if you want to consume the HSM service, you can just consume it. It provides you a lot of flexibility. So basically if you want to consume the cloud HSM, you need to follow some basic steps. So most of the cloud HSM will follow in the PCS-11 standard. So firstly, you might want to onboard your security keys in the cloud HSM. So the cloud HSM after you onboarding your private keys, it will give you a private key handler or key reference here. Then you can use this key handler in your application. Then when your application is running, he can use the key handler and send the crypto operation request to the cloud HSM. So cloud HSM actually will perform the crypto operation in his environment and give the crypto operation result to the application. So you can see actually in this scenario, the crypto operation is happened remotely against your application. So obviously it will bring your high latency for the crypto operations. At the same time, it also means you will have a lower transaction rate. At the same time, sometimes you want to migrate between different cloud providers. So although most of them are following the same PCS-11 standards, but the API might have a slight difference. So it will bring you a migration difficulty. The last part is on the edge side. Actually, there is no suitable replacement for the cloud HSM. So how to overcome all these challenges? This is what the distributed HSM we have brought up. So you can see from this picture, the big difference here is distributed HSM is actually sitting alongside your application. So in this picture, you can see actually each application has their own distributed HSM here. Also, the crypto operations will happen locally in the distributed HSM. So it brings a lot of benefit for you. Firstly, it's high secured and even on the edge, you can have your own distributed HSM and do the crypto operations inside it. So it is a lower latency and it will bring you a great throughput. Also, because this distributed HSM doesn't rely on additional hardware comparing to the traditional traditional HSM. So it also means lower cost. Besides this, you can see actually there are four steps here. There are additional step one. So this means before you give your credential information to the distributed HSM actually you can ask evidence beforehand to let the distributed HSM to prove to you that I'm actually a trusted party. So all this give you a lot of benefits here. So you might be curious how we can achieve this. So the answer is using trusted execution environment. So let's see what's the trusted execution environment. So basically, this is coming from the confidential computing area. So trusted execution environment provides you an isolated or protected environment to run your authorized code. So from security's perspective, the data can be divided into three categories. Data at rest, data in emotion and data in use. So for data at rest, the most popular technology is before you see your data, you can encrypt it and then see it in the disk or some storage. Data in motion means typically you can use in TLS or even mutual TLS to encrypt your traffic when the traffic is in transition. The last part is data in use. So this is the major focus for TE. So it means when the data is currently executing, it is protected as well. So basically TE will require some hardware or firmware support. It can, you can see from the right part it actually isolate applications and some privileged software like the operating system or even the hyper-wider cannot access this memory region and only the CPU is trusted. So as I said, it also can do the demonstration to your like the quote or adaptation. So you can see this is actually a trusted party. For example, this is really a trusted execution environment and I can for sure deliver my secret to you and let you run my crypto operations within your TE environment. Sorry, my computer hung here. So sorry for the interruption. So Intel SGX software guide extension is a kind of TE. So it's a process-based TE. So basically Intel CPU has some specific instructions that you can leverage it to create a protected environment and let you to, the protected environment in the top, it is called SGX Entry. So you can see from the right side picture, it looks like protected keys that other parties even like the operating system or the firmware, they cannot go into there and execute and access this memory region. So basically, if you want to leverage SGX, you can write your application and divide it into two parts, the trusted part and the untrusted part. Only the trusted part can go into the SGX enclave. So this memory region is encrypted and it has strict access control. So the remote attestation means it will prove to you it's a really trusted body and the ceiling means even if the computer has been restarted, you can still get your secret back. So SGX has been in the market actually for a long time as well. So basically the current, most of the current Intel server like the ISLIC has already supported this function. So if you are interested, you can use this link to find the detailed production information that support SGX. So maybe actually in your head, if you have an Intel server, it's actually already supported this. So you just need to enable it in buyers and you can leverage this capability in your environment as well. So let's see some user case, how we learned this in our real world. So in today's session, I will use the Easter service mesh as an example. So Easter, the security is an important part that it provides. So it has two cases, the mutual TS. So this is majorly using the communication within the mesh. The other is the gateway. So it will handle the traffic coming through the outside world like the user request coming through the gateway and then go into the mesh inside. So in these two cases, they have a private key here. And currently the Easter upstream, the private key will be in clear text. So it will bring security for you. A lot of security risk. You can imagine if the private key has been compromised, it will bring a lot of trouble here. So this is the new architecture that we leverage the distributed HSM that can enhance all these old risks. So you can see here, for the annual sidecar, we will inject SDS server here. There is SDS server here. This is a new component divided by ourself. And you can see there is a log in the annual and the SDS server. This log means there is a HSM alongside with them, which is implemented using SDS entirely. So let's take a closer look at the annual side. So you can see here, there is a, so for the annual side, see by default using boring SSL for their SSL library. So boring SSL has a private key provider mechanism. So we just leverage it and provide a SDS private key provider. And we will have, we will utilize the crypto API toolkit to generate or establish SDS environment for us. So this is the detail in the annual side. This is the SDS server side. So this is actually running SDS enclave. The distributed SSM is running alongside it. So basically we have local HSM while SDS enclave and the crypto operations are happening locally. And the credentials can be synced from remote HSM or locally generated. So for MutualTIS case, the private key is generated locally. For the gateways, it can be uploaded from remote case. Like your vault or you have your own key server. You can sync the keys securely in the enclave. So for the MutualTIS and the gateway, we also have the data plan part and the control plan part. So I will split them and let's take a look at them one by one. So the first user case is the MutualTIS control plan part. This is the picture for the current Istio flow. So basically Istio will let you delegate your CE functions to the external side, so to the external CE. So the whole flow is like first, there is an SDS server running inside the Istio agent. Yeah, running in here. And as an role, we are sitting together with the Istio agent. This is a whole Istio proxy pod. So when the Istio proxy pod is started, it will generate the private key pair. So you can see this marked in red. The private key is in clear text in memory. This is the first step. Then it will generate the CSR. I mean the Istio agent will generate the CSR, the certificate signing request, and it will send it to IstioD and IstioD will send out the CSR to the Kubernetes API server and the CSR will finally go into a CE. So in our case, we have a CE component is called trusted certificate service. So this service will get the CSR and sign the third back. So you can see now in step seven, step eight, and finally the private key and the third will be delivered to Enwall. So now Enwall has the private key and the third, but now it's in clear text. So this is the original flow. Let's see, after our enhancement, what's the current flow now? So here, we can see the, we have the SDS server here, but it's not running inside the Istio agent. It's the new component we just, we newly added. So this SDS server is running here. So it has an enclave here. So when the, it will sitting alongside the Enwall, so this will running in the same part. So when this is started, it will first initialize the SDS enclave and it will generate the private key pair in this enclave. So you can see now the key has been guided using this trusted execution environment. And then it will generate a CSR and the quote. So quote is some evidence to prove that I'm really a trusted environment. Then comparing with the original CSR, the difference here is the quote has been embedded into the CSR as an extension. So now the CSR has to be generated and following the original flow coming to the trusted certificate service. The trusted certificate service that will recognize this extension and extract the quote and it will generate a quote, a hesitation customary source. So we have the quote, a hesitation controller here. So it will using, it will get the quote and call our Intel's attention service to do the attention to make sure this is really a trusted hardware is a very healthy and secured environment. Then after this attestation has been done, the TCS, I mean the trusted certificate service, it will assign the setback. So if the attestation failed, you cannot get the setback. So you can see all this chain is very secured. And finally, the third will come back. And then you can see here, the private key actually in this step, it has been sealed using the CTK token file because these two enclave are sitting in the same part. So it can get the sealed key into his enclave. And because in this channel, in this current channel, the certificate and the private key config, we will generate the related information. So now the M1 will get the SDS private key provider information and the signed setback. So this is the whole flow after our enhancement. So you can see now, it also leverages external certificate authority and the private key in the whole path is never exposed in clear text. And the third is only issued if the attestation passed. And the crypto operations can be done locally. So this is another user case, the gateway case. So you can see from the Easter upstream, the gateway case to upload, I mean to make the key available to the M1 is a long journey. So you can see due to time limitation, I cannot go through the details, but if you are interested, you can take a look at this picture. But basically you can see in all these steps, this private key is in clear text. For example, in these steps, in the first step, the admin upload of the private key and the third in the secret. So anyone can, if he has the authority, he can get the secret and he can get the private key. So it's really dangerous. And it's the long journey in the Easter D, in the Easter agent and finally in M1, all this in clear text. So this is the flow after our enhancement. So you can see here, the first step is create a gateway customer results. And then after the SDS server is also running here. So you can see the SDS server is actually the same SDS server because we're using the same SDS server so both the gateway and the MTRS case. So that SDS server will have to be moved out from Easter D and it's coming here. And from this long journey, it will come into the enclave. So maybe I can explain further because this little complex. So first the domain create the gateway customer results and then the SDS server will watch this customer results and after that it will initialize the SDS enclave and then we'll create the key pair. But this key pair is not the final key pair for M1. It's just using to write in user's private key here. So the KMI here actually is a key storage server. So basically you can replace it with your own key storage server. So you can see in the, this is the first step, the second step and then we will generate a quote like previous case under the public key here and then the attached controller will help us do the adaptation. Meanwhile, because in the gateway customer results you will get with the key handler information in the KMI here or your key storage. So you can, so the attached controller will help you wrap the private key using the public key generated here. So it means only this guy, this SDS enclave guy because the private key is sitting here so only him can unwrap the key. So this makes sure that the whole chain is secured. So now after the wrapped key coming here and it will be unwrapped and then finally it will come into this M1 guy. So this is the whole flow. Let me know if you have any questions. So, yeah, previously they are in clear text and the private keys are uploaded externally. So after it's also, the private keys is also coming off site but the whole upload chain is secured and the private key is never exposed off site in clear text and the keys only get updated if the attestation passed and finally the clipped operation is happened locally. So let's take a look at the data plan part. The data plan part means when the traffic coming, how it happens. So this is the original, how M1 works. So when there is a new HTTPS request comes, the TS hash it will happen here. So the Bowering SSL library, we are using the private key in memory to do the sign or decrypt operation and then return the result back. Now, because NWO has the SGX enclave here and we have the SGX private key provider here. So now after we get the TS hash request, this request will be delegated to SGX private key provider and the provider will send the request to the local SGX enclave and all the sign and the decrypt operation will happen in this trusted environment and then finally it will get the result back. So this is very secured and because the current operation has happened locally, so the performance penalty is very little. The other case is the certificate authority case. So in the same case, the C also need a private key here. So our solution is called trusted certificate service. So it can handle incoming certificate signing request. So in this trusted certificate service, it also has the SGX enclave. So it has a part of two cases, self-signed third or the external uploaded C case. So for the first case, the C private key will generate the locally and we are serving and using this private key to handle the incoming CSRs. In the latter case, the private key will be uploaded to the other side from other sideward. So a little similar to the gateway case, we will also do a hesitation and wrap the key and I wrap the key. So this is the detailed flow for this. So the upper part is how we upload the case and the latter part is how, if you leverage it in E still D, how you E still, how you can leverage it. This is the sample YAML file that you can leverage this solution. So actually, this solution, the HSM server, we have already open sourced in the E still ecosystem on the data.github repo and all the onward changes also in public repo. So you can just grab that repo and using this YAML file to have a try if you have interest. So some future step we want to take, you know, actually there are a lot of cloud HSM here. We want to do some adapter here that can, you know, if your keys are stored in this area and your application is remote to this one, then we can have an adapter here to help you think the private keys or any credential information in your local distributed HSM, then you can do the operation locally. So we hope we can provide a unified API for the users. So whether your application is around AWS or Microsoft, you can use this unified API and get the benefit for the distributed HSM. And then, you know, all the current operations can happen locally. These are some of the GitHub repo we used. So the first one is the Istio repo. The second one is the M1 part. And then the SDS server part, this is under Istio repo. This is the same one. This is our Intel key storage reference architecture, but actually you can use your own key storage server. And this is the C, this is the C, this is the attaching controller part. And we also have a EHSM solution. So it's open source, it's also leveraging SDS enclave, so you can have a try. And this, you know, for the Istio part, we actually rely on the external C function. So this is the reference document. Okay. Yeah, so I hope you can explore and join us and you know, all this GitHub repo is public. And if you have any questions or issues, you can just submit it. NNPRs are just very welcome. Yeah, that's all. Thank you. Thank you, thank you very much.