 Good afternoon. It's already late. Today I'm sharing with you about combination of hyperlogic fabric plus Intel SGS. So I use a very good description like installing hardware wallet for consulting blockchain. So what is hardware wallet? So let's use blockchain hardware wallet as an example. We know that the most important thing from blockchain wallet is private key and we need to have a hardware to protect the private key. So maybe when people have wallets, they have a lot of coins or they pay a lot of attention to security. So there are several steps. The first step is that you need to put the private key into the wallet. More accurate description is that the private key will never go out of the wallet. The private key will be generated by the wallet and when you are doing transaction with blockchain you need to have a signature and the whole transaction process after you do the transaction. You need to send a request for signature and internally the wallet needs to calculate about the signature script and throughout the process the Bitcoin will be in a very secure state. You don't need to worry about any theft or any virus that will attack your wallet. In the consulting blockchain, if we are using hybrid or hybrid as an example so every consultant knows will have private key. For example, for peer, it needs to do the endorsement after every transaction for order and needs to have a signature of the transaction. No matter for peer or order, private key reflects the authority or identity which are essential for the consulting. This is also something we want to protect the private key of the users for that reason. And we decided to choose SGX Technology from Intel. Actually this is the programmable internal environment. It has the concept of enclave. So you can put some codes into the CPU for operation and the operations will be encrypted before putting on the CPU. If you trust the Intel CPU, all of those codes will be encrypted so it can play the role of hardware wallet for us. So our goal is that we want to use SGX Technology to protect fabric node private key. So we gone through two solutions and three steps to achieve that. When we look back on this, the first one is about the public part because we need to prepare the SGX environment including software library and related Intel's lib and drives. We also need to have internal crypto library within the enclave. In the beginning we didn't think about the fabric. We didn't touch upon the fabric private key. We just added the Golang crypto lib. So we hijacked the encrypted one and turned it into a logic that can run within the environment. Second solution is we have changed the fabric BCCSP so that we can achieve SGX based plug-in BCCSP. The first part is about the installation of the joint based on the header file of the core. And the second is we need to establish the related SGX surveys. If it is not very common Linux systems, we need to download the source code to do the transformer compilation and installation. Then we will use some common password database. For example, for OpenSSL, we cannot run in such SGX Linux environment. So under this circumstance, we need to use the OpenSSL, which can run in such environment. So after Intel done some modifications on the OpenSSL, we have got this database of the password. So we will download the source file of the SGX OpenSSL and then put it into some environment while it is working. And the third thing is because for the blockchain, the apps are running in Kubernetes or in containers. So if to support the running in containers, we need to have the virtual equipment and install some of the modules in the containers. So for this part, if you have interest tomorrow at 10.20, we will have some SGX experience that is made. Lee Xiao-min will give you a lecture at 10.20 tomorrow. So after doing that, we can achieve our target. So the first try is to hijack the Golang crypto lab. This is the architecture lab. So we will not touch upon the code related to fabric. What we have done is on the Golang layer because the enclave related codes will be realized about C or C++ language. So if to invoke, C needs to have the Golang layer as the bridge. So that means on the Golang, we have the SGX and then the code can enter into a secure hardware wallet. So with that, we can realize the private key management and the related signature management. So this was what I have described, the different layers and their functions. And this is a goal for the ECTSA. We have the generation of the private keys and the interface of signatures. And one interface will be used very commonly is to reduce the public keys from the private keys. So that means we need to map the logics into the enclave, that is the hardware wallet. Then after the hardware wallet has done the calculations to fit back on the calculation result. So that is why we need to change some of the interface in Go. And after changing on the Golang, we are going to realize the SGX interfaces. So that means for SGX, they need to have the generation of private keys, signatures of private keys, and the deduction from the private key to the public key. So this is in the inside of the hardware wallet. We need to have the different interfaces to be realized. But this will be very easy because we can use the algorithm of the open SSL to do a very simple in packaging and encapsulation so as to generate the interface for private key generation. And also for the private key signature interface, it is the same. That is under the enclave environment, we need to have some encapsulation of the open SSL interface. And this is about how to get the public key from the private key. So what we need to pay in mind is the private keys generated from the open SSL, whether there are differences to the Golang private keys. So that is why some of the ECDSA curve the points, we need to have the encapsulation of those. So that is the proposal, that is the relatively simple proposal. And at that time, we didn't have a very full in-depth understanding of fabric. And then after studying on the source code of fabric, we think that fabric has very good modularities. They have put the cryptography related interface in one module. So designing this module, they have taken into account to use the plug-ins of Golang language, that is kind of PCCSP module. So we are kind of thinking whether we can use that to realize a SDX-based plug-in PCCSP. And then behind the modules is connected to the hardware wallet. So that is what we have tried. So while doing this, there are several steps we have taken. First is for the PCCSP of fabric. It has the plug-in supporting design, but because the interface design has a lot of dependencies, the plug-in needs to be coupled with the source code of the fabric. So that will also give some difficulties while we are realizing the hardware wallet. So that means we cannot decouple the compilation. So what we have come up with is to enhance the PCCSP interface to decouple the dependencies. And then based on that, we have realized the PCCSP interface. So what we have done is two things. One is to support SDX, and the other is to support some of the Guomi related algorithm. And these two actually are in a positive relationship. So that means SDX supports the Guomi algorithm. So this is the original interface of the PCCSP. We can see that it is clearly defined, including the private keys, the parameters of the private keys and some of the core interface and the generations of public keys and signature. And this is the modified plug-in PCCSP interface. So from this, we can make a comparison with the previous one. The obvious difference, for example, is if you have a look at this interface, if to get a public key from the private key for the original interface, what they are sending is a key which is, and for example, for the signature interface, it is inputting some like private keys or parameters. So that means this interface are relying. If you want to use this interface definition, you must have the goal language to know that what is the private key and which package it is in. So that actually will lead to the decoupling that will not help on the decoupling. So that is why we have done some modifications. If there is any interface which is relying or have some dependence, we will just modify it into the plug-in PCCSP interface. So with this, we can see that the data structure of the PCCSP is consistent of the key data structure and that will help us to realize a total plug-in PSSCP interface. So the reasons we do this is because we hope that for fabric, the plug-in and the fabric, they build the release or the version management process can be separate. And if you want to know more about the goal plug-in restraints, you can click on the link here. It is about some of the design restraints for the goal plug-in module. And also we have some PR for the community for it to think about whether to decouple the compilation of plug-in and the goal and fabric. So next, things will become easier. That is when the interface has been consistent, the following things will be very similar to the proposal one. In the PCCSP, we are going to have the generation of the public key, private keys, the signature of private keys, and then there are any private keys to get the public key interface. So all this interface has been realized. And while implementing this interface, we will redefine the related logics into the SDX enclave, that is the hardware wallet environment. And then the private key in that wallet can help generate the private key. So that means the private key is fixed in the wallet. And also it is allowed to instill some private keys into the wallet. And for the signature private keys, the signature will be generated in the wallet, so as for the private key not to be disclosed from the wallet. After doing that, we can carry over some of the steps in proposal one, like the generation of the private keys and the ceiling of the private keys. Ceiling of private keys means that if you want to have a private key durable, you can have a sale interface from SDX. And then you will get an encrypted result. So the result can only be decoded or decrypted in the same CPU. And then the following steps will be similar to the proposal one. And then for the iDCloud blockchain services, why we are launching the solution two and giving up on option one. There are several reasons. One reason is because of our project. We hope that SDX enhancement is an optional configuration because right now Intel support to SGX is only for some of the CPUs. So on iDCloud, the user has to use some high-level service where SGX support it. In the future it will be a very general solution. Any cloud service would have that capability. In the future there will be virtualization capability, but right now it's not very popular. That's why we want it to be an optional configuration. That means in overall we can have a set of codes, a set of mirrors of fabric. And while we are doing the deployment or use the triggered blockchain deployment, according to different configurations, we will determine whether we need to turn on the hardware's wallet logic. If we're choosing the option one by modifying the goal line, it's very difficult to transfer the private key through the existing port. We need to use different goal language to write two different sets of codes. And then we can choose different fabric mirrors. We find it to be a very imperfect accomplishment. And also in terms of code management and for our debugging, it will double our workload and including mirror management publication. Because for option one there are some limitations or different versions, we need to double our efforts. Another thing is about scalability, because in order to achieve a hardware wallet, actually for the current implementation, hardware wallet is still being dominated by Ali Cloud for the code reliability and wallet security with their endorsement. But for some high-security users, they have a pursuit, like they don't necessarily trust you. They want to have their own hardware wallet. So our platform can provide an capability where the user can provide customized enclave solutions. They can create their own hardware wallet, and then they can use their own private key signature to upload it on the cloud. That means the user has completely control of the hardware wallet, although for the physical machines and the cloud is controlled by us. But as long as the enclave mechanism has no security issues, and we have no way to touch upon on the core data where the user has put on the cloud, that means the user can have complete control of the private key. Meanwhile, they can also enjoy the convenience of cloud computing, and they can also use blockchain and all other functions on the cloud. So this is another consideration for us. While we are realizing option two, this kind of architecture would make it very natural because they can have their own BCCSP implementation or their own enclave interface so that we can help them to implement that. Do you have any questions? I have a question. The first question is, you have mentioned about... Actually, I have two questions. The first question is, you have mentioned that the Intel SGS has integrated to the Go. Now we don't have a mechanism that can achieve key rotation. Is that correct? Because we can only generate the key once because we have only one interface when we have the bridge front fabric to the Intel SGS. So the key is generated only once, and then it will be put in the enclave. So we are calling that key every time when we're using that, but we cannot have a rotation of the private key, right? You understand it's correct. In fabric, we can go back to the previous slide. Actually, in the fabric, the key rotation, so when some nodes is initiated, it will find corresponding CA or CAC organization for signature and dispatch, and then it will always use that key. It depends on the CA organization for peer or order certificates. How long is the exploration time? If you want to have a rotation, you can redo that. If it is consortium chain, CN needs to regularly update the certificate. So when the node is initiated for the signature, there will be an exploration time, like for one year or several years. It depends on the configuration. Actually, you need to do some additional things. You need to have a timer. So after some time, the private key needs to well inspire. So another key will be generated in option 2. The fabric has the key rotation feature. I don't remember very well. Actually, we're doing this based on version 1.2. I think it doesn't have that. But I think maybe for 1.4. Maybe. Fabric is not doing a key rotation. If it has an MX reload, you can add additional outlet for the key rotate. If you have rotated the key, and it can load the key. I think they have really done that in 1.4 version. But I'm not sure about this. If they are doing that with version 1.4, that would be okay. The second question is, I understand that only Tom Long's thing can use Intel's SGX. Yes, as I've said. Because as the support to virtualization is not so good now. The second thing is that for Intel 1.5 CPU hasn't started with their ball production. Because they are supporting desktop and E3 workstation for AliCloud, for Shun CPU. They're using E3 CPUs. Some of the bare metal CPUs can use that. So I don't understand about one thing. If it is a virtual process. So imagine we are using bare metal. We have eight servers. Maybe there are two CPUs. For these two CPUs. I don't know which CPUs Intel's power key to generate the private key. So actually, I don't understand it. So for these two CPUs, which CPU should I use to generate the power key? It's in the same package? But because it's virtual, I don't know as a user, as the peer, when I generate the private key. I don't know which CPU is coming from. It's in the same package. I think there are two questions here. The first one is, on which CPU is the peer running? Actually, for Shenlong servers for bare metal, they wouldn't have the migration of the servers. You will always be running on the same CPU. When you have multiple cores on the same CPU, this is my personal understanding. When they are sharing one SGS environment, they can all decrypt the seal thing. So if it is not migrated, I can understand it. I think if that migrates, it will be chaotic. It has stress, calls, package. So when it's on the same package, it's okay. Because they're going to fuse that. Okay, thank you. I happen to have a question here. My understanding is, I checked some API interfaces. I don't know my understanding is correct. Although the private keys are generated in the enclave, but the interface is blank for the sign. Do we have an authorization mechanism? Otherwise, anyone can go to the enclave on the processing platforms when you have multiple releases, and you can load the enclave and startup, and then you can send your message and call the sign API. You can also sign. So do you have an authorization mechanism so that sometimes it will not sign? Actually, for the sign interface, you need to send the seal key and the content you are assigning. So for the seal key, sorry, for interruption, for the seal key, it's saved on some location. And SG can also be run on other machines. Although they don't know what is saved there. SGS is a binary. They know how the interface is calling that. So coming back to my question, right now we don't have an authentication mechanism. The main reason for that is that for the up-to-layer deployment, the fabric software can call sign anytime. It's not easy to do some good authentication about the environment. If it's really a hardware wallet, normally it will have a fingerprint or pin code to access that. It's because for every transaction a Bitcoin is initiated by the user, but for the fabric, because their nodes are passive, so you need to use the private key to do the signature. In order to do that, we need to do something about the peer process or the environment. According to our evaluation, it will be difficult and we cannot trust the environment will not be attacked. That's why we haven't done anything for that part yet. Thank you. My question is, maybe I don't know too much about enclave. My question is, that means the key cannot leave the machine, right? Suppose your machine breaks down, what happens? This is a very good question. That's why in the enclave, we have some protection about the data reliability because we believe enclave is a relatively safe environment. Once the CPU breaks down, the seal key will never be decrypted, so the data can no longer be used. That's why we need to use measures with higher security level to have a backup of the private key. That's why behind the enclave, we have achieved some export of the private key to HSM. This additional protection is to ensure that we can recover the data. The private key can still be exported. After decryption, you can export that to HSM and then it can be exported to another machine, right? It's like a private key input and export between two decrypted machines. You can send the result there. During the transport, there is no open message and the process of recovering data is the same. We're going to generate a public key so that the HSM can decrypt that. For the local enclave, you need to decrypt the private key and then use the private way to put that into a local drive. The whole transfer process is utilizing an additional device for the decryption so that the private key can be circulated between these hardware. Thank you.