本說明書提出一種可信應用程式的遠端證明方法，所述可信應用程式中的受保護碼被隔離載入在作為可信執行環境的目標容器中，其中，所述受保護碼包括待執行碼，和用於產生私鑰以及公鑰的目標函數，所述方法包括：
呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰，並對產生的私鑰進行加密，以及對加密後的私鑰進行持久化儲存，其中，加密的所述私鑰被設置了僅由所述目標容器進行解密的解密策略；
透過第三方遠端證明服務端向遠端接收對象發起針對所述公鑰的遠端證明，並在所述公鑰通過遠端證明時，將所述公鑰發送至所述遠端接收對象進行持久化儲存；
獲取所述待執行碼的執行結果，其中，所述執行結果由所述目標容器基於解密出的所述私鑰進行了簽名處理；
將所述執行結果發送至所述遠端接收對象，以由所述遠端接收對象基於儲存的所述公鑰對所述執行結果的簽名進行驗證，來確認所述執行結果是否為可信資料。
可選地，呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰，包括：
回應於所述待執行碼的執行指令，呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰；或者
基於預設的呼叫週期，週期性呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰。
可選地，透過第三方遠端證明服務端向遠端接收對象發起針對所述公鑰的遠端證明，並在所述公鑰通過遠端證明時，將所述公鑰發送至所述遠端接收對象進行持久化儲存，包括：
基於產生的所述公鑰創建遠端證明憑證；
將所述遠端證明憑證發送至所述第三方遠端證明服務端，以由所述遠端證明服務端對所述遠端證明憑證進行驗證；
獲取所述遠端證明服務端返回的驗證結果，其中，所述驗證結果由所述遠端證明服務端基於持有的私鑰進行了簽名處理；
將所述驗證結果以及產生的所述公鑰發送至所述遠端接收對象，以由所述遠端接收對象至少基於所述第三方遠端證明服務端的公鑰對所述驗證結果的簽名進行驗證，並在所述簽名驗證通過後，將產生的所述公鑰在所述遠端接收對象本地進行持久化儲存。
可選地，所述可信執行環境為基於SGX技術搭建的可信執行環境，所述目標容器為SGX技術中的Enclave程式，其中，加密後的所述私鑰的解密策略被設置為keypolicy-MRENCLAVE策略。
可選地，所述遠端接收對象為發布至區塊鏈的智慧型合約。
本說明書還提出一種可信應用程式的遠端證明裝置，所述可信應用程式中的受保護碼被隔離載入在作為可信執行環境的目標容器中，其中，所述受保護碼包括待執行碼，和用於產生私鑰以及公鑰的目標函數，所述裝置包括：
產生模組，呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰，並對產生的私鑰進行加密，以及對加密後的私鑰進行持久化儲存，其中，加密的所述私鑰被設置了僅由所述目標容器進行解密的解密策略；
證明模組，透過第三方遠端證明服務端向遠端接收對象發起針對所述公鑰的遠端證明，並在所述公鑰通過遠端證明時，將所述公鑰發送至所述遠端接收對象進行持久化儲存；
獲取模組，獲取所述待執行碼的執行結果，其中，所述執行結果由所述目標容器基於解密出的所述私鑰進行了簽名處理；
驗證模組，將所述執行結果發送至所述遠端接收對象，以由所述遠端接收對象基於儲存的所述公鑰對所述執行結果的簽名進行驗證，來確認所述執行結果是否為可信資料。
可選地，所述產生模組：
回應於所述待執行碼的執行指令，呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰；或者
基於預設的呼叫週期，週期性呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰。
可選地，所述證明模組：
基於產生的所述公鑰創建遠端證明憑證；
將所述遠端證明憑證發送至所述第三方遠端證明服務端，以由所述遠端證明服務端對所述遠端證明憑證進行驗證；
獲取所述遠端證明服務端返回的驗證結果，其中，所述驗證結果由所述遠端證明服務端基於持有的私鑰進行了簽名處理；
將所述驗證結果以及產生的所述公鑰發送至所述遠端接收對象，以由所述遠端接收對象至少基於所述第三方遠端證明服務端的公鑰對所述驗證結果的簽名進行驗證，並在所述簽名驗證通過後，將產生的所述公鑰在所述遠端接收對象本地進行持久化儲存。
可選地，所述可信執行環境為基於SGX技術搭建的可信執行環境，所述目標容器為SGX技術中的Enclave程式，其中，加密後的所述私鑰的解密策略被設置為keypolicy-MRENCLAVE策略。
可選地，所述遠端接收對象為發布至區塊鏈的智慧型合約。
本說明書還提出一種電子設備，包括：
處理器；
用於儲存機器可執行指令的記憶體，
其中，透過讀取並執行所述記憶體儲存的與基於區塊鏈的可信應用程式的遠端證明的控制邏輯對應的機器可執行指令，所述可信應用程式中的受保護碼被隔離載入在作為可信執行環境的目標容器中，其中，所述受保護碼包括待執行碼，和用於產生私鑰以及公鑰的目標函數，所述處理器被致使：
呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰，並對產生的私鑰進行加密，以及對加密後的私鑰進行持久化儲存，其中，加密的所述私鑰被設置了僅由所述目標容器進行解密的解密策略；
透過第三方遠端證明服務端向遠端接收對象發起針對所述公鑰的遠端證明，並在所述公鑰通過遠端證明時，將所述公鑰發送至所述遠端接收對象進行持久化儲存；
獲取所述待執行碼的執行結果，其中，所述執行結果由所述目標容器基於解密出的所述私鑰進行了簽名處理；
將所述執行結果發送至所述遠端接收對象，以由所述遠端接收對象基於儲存的所述公鑰對所述執行結果的簽名進行驗證，來確認所述執行結果是否為可信資料。
在以上技術方案中，一方面，由於用於遠端證明的公私鑰對在作為可信執行環境的目標容器中自主產生，不再由軟體提供商來產生；並且，持久化儲存的加密後的私鑰被設置了僅由該目標容器進行解密的解密策略；因此，即便是軟體發展者也無法獲取到產生的私鑰，從而可以顯著提升私鑰的安全等級；
另一方面，由於可信應用程式僅需要透過第三方遠端證明服務端，向遠端接收對象發起一次針對自主產生的公鑰的遠端證明，並在該公鑰通過遠端證明之後，後續就可以直接使用產生的私鑰對受保護碼中的待執行碼的執行結果進行簽名，並將簽名後的執行結果發送給遠端接收對象完成針對該執行結果的遠端證明，而不再需要透過第三方遠端證明服務端來向遠端接收對象發起針對該執行結果的遠端證明；因此，可以不再需要與第三方遠端證明服務端進行頻繁的互動，就可以基於自主產生的公私鑰對就可以便捷的向遠端接收對象證明該執行結果為可信資料。This specification proposes a method for remote certification of a trusted application program. The protected code in the trusted application program is isolated and loaded in a target container as a trusted execution environment, where the protected code includes a pending execution Code, and an objective function for generating a private key and a public key, the method includes:
Call the target function to generate a private key and a public key in the target container, encrypt the generated private key, and persistently store the encrypted private key, wherein the encrypted private key is set A decryption strategy for decryption by the target container only;
Initiate remote certification of the public key to the remote receiving object through a third-party remote certification server, and when the public key passes the remote certification, send the public key to the remote receiving object for Persistent storage;
Acquiring the execution result of the code to be executed, wherein the execution result is signed by the target container based on the decrypted private key;
Sending the execution result to the remote receiving object to verify the signature of the execution result based on the stored public key by the remote receiving object to confirm whether the execution result is a credible material .
Optionally, calling the target function to generate a private key and a public key in the target container includes:
In response to the execution instruction of the code to be executed, calling the target function to generate a private key and a public key in the target container; or
Based on a preset call period, the target function is periodically called to generate a private key and a public key in the target container.
Optionally, a third-party remote certification server initiates remote certification of the public key to the remote receiving object, and when the public key passes the remote certification, the public key is sent to the remote Objects receive persistent storage at the end, including:
Create a remote certificate based on the generated public key;
Sending the remote certificate to the third-party remote certificate server to verify the remote certificate by the remote certificate server;
Obtaining the verification result returned by the remote certification server, wherein the verification result is signed by the remote certification server based on the held private key;
Sending the verification result and the generated public key to the remote receiving object, so that the remote receiving object signs the verification result based at least on the public key of the third-party remote certification server Verification, and after the signature verification is passed, the generated public key is locally stored in the remote receiving object locally.
Optionally, the trusted execution environment is a trusted execution environment built based on SGX technology, and the target container is an Enclave program in SGX technology, wherein the decryption policy of the encrypted private key is set to keypolicy- MRENCLAVE strategy.
Optionally, the remote receiving object is a smart contract issued to the blockchain.
This specification also proposes a remote certification device for a trusted application program, and the protected code in the trusted application program is isolated and loaded in a target container as a trusted execution environment, wherein the protected code includes a pending An execution code, and an objective function for generating a private key and a public key, the device includes:
A generating module, calling the target function to generate a private key and a public key in the target container, encrypting the generated private key, and persistently storing the encrypted private key, wherein the encrypted private key The key is set with a decryption strategy that is only decrypted by the target container;
The certification module initiates remote certification of the public key to the remote receiving object through a third-party remote certification server, and sends the public key to the remote when the public key passes the remote certification The end receives objects for persistent storage;
An obtaining module to obtain an execution result of the code to be executed, wherein the execution result is signed by the target container based on the decrypted private key;
The verification module sends the execution result to the remote receiving object to verify the signature of the execution result based on the stored public key by the remote receiving object to confirm whether the execution result As credible information.
Optionally, the generation module:
In response to the execution instruction of the code to be executed, calling the target function to generate a private key and a public key in the target container; or
Based on a preset call period, the target function is periodically called to generate a private key and a public key in the target container.
Optionally, the certification module:
Create a remote certificate based on the generated public key;
Sending the remote certificate to the third-party remote certificate server to verify the remote certificate by the remote certificate server;
Obtaining the verification result returned by the remote certification server, wherein the verification result is signed by the remote certification server based on the held private key;
Sending the verification result and the generated public key to the remote receiving object, so that the remote receiving object signs the verification result based at least on the public key of the third-party remote certification server Verification, and after the signature verification is passed, the generated public key is locally stored in the remote receiving object locally.
Optionally, the trusted execution environment is a trusted execution environment built based on SGX technology, and the target container is an Enclave program in SGX technology, wherein the decryption policy of the encrypted private key is set to keypolicy- MRENCLAVE strategy.
Optionally, the remote receiving object is a smart contract issued to the blockchain.
This manual also proposes an electronic device, including:
processor;
Memory for storing machine executable instructions,
Among them, the protected code in the trusted application is isolated by reading and executing machine-executable instructions stored in the memory corresponding to the control logic of the remote certification of the blockchain-based trusted application Loaded in a target container as a trusted execution environment, where the protected code includes the code to be executed, and a target function for generating a private key and a public key, and the processor is caused to:
Call the target function to generate a private key and a public key in the target container, encrypt the generated private key, and persistently store the encrypted private key, wherein the encrypted private key is set A decryption strategy for decryption by the target container only;
Initiate remote certification of the public key to the remote receiving object through a third-party remote certification server, and when the public key passes the remote certification, send the public key to the remote receiving object for Persistent storage;
Acquiring the execution result of the code to be executed, wherein the execution result is signed by the target container based on the decrypted private key;
Sending the execution result to the remote receiving object to verify the signature of the execution result based on the stored public key by the remote receiving object to confirm whether the execution result is a credible material .
In the above technical solution, on the one hand, since the public and private key pair for remote certification is generated autonomously in the target container as a trusted execution environment, it is no longer generated by the software provider; and, the encrypted The private key is set with a decryption strategy that only the target container decrypts; therefore, even software developers cannot obtain the generated private key, which can significantly improve the security level of the private key;
On the other hand, since the trusted application only needs to pass a third-party remote certification server, it initiates a remote certification of the publicly generated public key to the remote receiving object, and after the public key passes the remote certification, the subsequent You can directly use the generated private key to sign the execution result of the code to be executed in the protected code, and send the signed execution result to the remote receiving object to complete the remote certification of the execution result, without the need Through the third-party remote certification server to initiate remote certification of the execution result to the remote receiving object; therefore, it is no longer necessary to interact frequently with the third-party remote certification server, and it can be based on the publicly generated private key You can easily prove to the remote receiving object that the execution result is credible data.
在實際應用中，通常可以透過搭建TEE(Trusted Execution Environment，可信執行環境)，並將可信應用程式中的受保護碼，在TEE中進行隔離，來實現對這些受保護碼的安全防護。
其中，在搭建TEE時，通常可以將設備底層的處理器作為硬體支撐，來搭建一個僅能由處理器來存取的容器(container)作為可信執行環境，並將可信應用程式中的受保護碼隔離載入在該容器中，以對容器中的受保護碼進行隔離保護。
例如，以利用Intel的SGX (Software Guard Extensions,軟體保護擴展)技術來搭建TEE為例，基於SGX技術，通常會將設備的CPU作為硬體支撐，來創建稱之為Enclave的程式作為保護容器，並將需要受到保護的碼隔離載入在Enclave程式中，保護其不受到攻擊。
而在一些場景下，上述可信應用程式中的受保護碼的執行結果，如果需要參與遠端的可信計算，則該可信應用程式除了需要將上述受保護碼的執行結果發送給遠端接收對象以外，通常還需要基於遠端證明技術，在不洩露受保護碼的基礎上，向遠端接收對象證明這些受保護碼的執行結果為可信資料。
例如，在一個場景下，假設部署在區塊鏈上的智慧型合約需要將可信應用程式中的受保護碼的執行結果作為輸入資料，在區塊鏈上進行可信計算；在這種情況下，由於可信應用程式並不是鏈上節點，對於智慧型合約來說是非授信的一方；因此，可信應用程式在將受保護碼的執行結果發送給部署在區塊鏈上的智慧型合約時，則需要依靠遠端證明技術，在不洩露受保護碼的基礎上，向智慧型合約證明這些受保護碼的執行結果為可信資料(即鏈上證明)。
而基於目前的遠端證明技術，可信應用程式向遠端接收對象發起針對特定資料的遠端證明時，通常需要依賴第三方遠端證明服務端來完成。
例如，仍然以Intel的SGX技術中的遠端證明機制為例，基於SGX技術，Intel會提供用於遠端證明的第三方的IAS(intel attestation service，因特爾認證服務)伺服器。隔離載入在Enclave中的受保護碼的執行結果，如果需要參與可信計算，則可信應用程式可以與IAS伺服器進行互動，透過IAS伺服器向遠端接收對象發起針對該受保護碼的執行結果的遠端認證，向遠端接收對象證明該受保護碼的執行結果為可信資料。
由於依賴第三方遠端證明服務端來完成遠端證明，需要與第三方遠端證明服務端進行頻繁互動，因此需要一種更加便捷的遠端證明機制。
基於此，本說明書提出一種基於作為可信執行環境的容器獨立產生的公私鑰對，來便捷向遠端接收對象發起對受保護碼的執行結果的遠端證明方案。
在實現時，可信應用程式的軟體發展者，可以基於特定的TEE搭建技術(比如，採用Intel的SGX技術)，來開發作為TEE的目標容器(比如，SGX技術中的Enclave程式)，並將可信應用程式中的受保護碼隔離載入在該目標容器中。
其中，在本方案中，隔離載入在上述目標容器中的受保護碼，可以包括執行結果需要向遠端接收方進行遠端證明的待執行碼，和用於產生私鑰以及公鑰的目標函數(本質上是一些產生私鑰公鑰的特殊碼)。
進一步地，可信應用程式可以呼叫隔離載入在上述目標容器中的受保護碼中的目標函數，在目標容器中產生一對公鑰和私鑰；
一方面，對於產生的私鑰，還可以在目標容器中進行加密處理，其中，在目標容器中對產生的私鑰進行加密時，可以為加密後的私鑰設置僅由該目標容器進行解密的解密策略(即僅該目標容器具有解密權限)；然後，由處理器將加密後的私鑰進行持久化儲存。
另一方面，對於產生的公鑰，可以透過第三方遠端證明服務端，向遠端接受對象發起針對該公鑰的遠端證明，並在該公鑰通過遠端證明時，將產生的該公鑰發送至遠端接收對象，由遠端接收對象進行持久化儲存。
後續，當上述待執行碼執行完畢，上述目標容器可以對上述加密的私鑰進行解密，基於該私鑰對該待執行碼的執行結果進行簽名處理。而可信應用程式可以獲取由上述目標容器簽名處理後的執行結果，並將該執行結果發送至遠端接收對象，來發起針對該執行結果的遠端證明。
遠端接收對象在接收到可信應用程式發送的執行結果後，可以基於已經儲存的公鑰，對該執行結果的簽名進行驗證，來確定該執行結果是否為可信資料。
在以上技術方案中，一方面，由於用於遠端證明的公私鑰對在作為可信執行環境的目標容器中自主產生，不再由軟體提供商來產生；並且，持久化儲存的加密後的私鑰，被設置了僅由該目標容器進行解密的解密策略；因此，即便是軟體發展者也無法獲取到產生的私鑰，從而可以顯著提升私鑰的安全等級；
另一方面，由於可信應用程式僅需要透過第三方遠端證明服務端，向遠端接收對象發起一次針對自主產生的公鑰的遠端證明，並在該公鑰通過遠端證明之後，後續就可以直接使用產生的私鑰對受保護碼中的待執行碼的執行結果進行簽名，並將簽名後的執行結果發送給遠端接收對象完成針對該執行結果的遠端證明，而不再需要透過第三方遠端證明服務端來向遠端接收對象發起針對該執行結果的遠端證明；因此，可以不再需要與第三方遠端證明服務端進行頻繁的互動，就可以基於自主產生的公私鑰對就可以便捷的向遠端接收對象證明該執行結果為可信資料。
下面透過具體實施例並結合具體的應用場景對本說明書進行描述。
請參考圖1，圖1是本說明書一實施例提供的一種可信應用程式的遠端證明方法，應用於可信應用程式，所述可信應用程式中的受保護碼被隔離載入在作為可信執行環境的目標容器中，其中，所述受保護碼包括待執行碼，和用於產生私鑰以及公鑰的目標函數，所述方法執行以下步驟：
步驟102，呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰，並對產生的私鑰進行加密，以及對加密後的私鑰進行持久化儲存，其中，加密的所述私鑰被設置了僅由所述目標容器進行解密的解密策略；
步驟104，通過第三方遠端證明服務端向遠端接收對象發起針對所述公鑰的遠端證明，並在所述公鑰通過遠端證明時，將所述公鑰發送至所述遠端接收對象進行持久化儲存；
步驟106，獲取所述待執行碼的執行結果，其中，所述執行結果由所述目標容器基於解密出的所述私鑰進行了簽名處理；
步驟108，將所述執行結果發送至所述遠端接收對象，以由所述遠端接收對象基於儲存的所述公鑰對所述執行結果的簽名進行驗證，來確認所述執行結果是否為可信資料。
上述可信應用程式，包括由軟體發展者開發的能夠向第三方提供可信服務的應用程式，其中，可信應用程式中的程式碼，通常包括受保護部分，和不受保護。
上述目標容器，在本說明書泛指基於特定的TEE搭建技術，搭建出的一個能夠為可信應用程式中的受保護碼提供安全保護的隔離的安全運行環境。
其中，在實際應用中，上述目標容器可以是一個以處理器作為底層硬體支撐，且僅能由處理器進行存取的隔離的軟體環境；例如，以採用Intel的SGX技術搭建TEE為例，上述目標容器具體可以是SGX技術中的Enclave程式，通常將可信應用程式中的受保護碼隔離載入到Enclave程式中，來對上述受保護碼進行安全防護。
當然，在實際應用中，也不排除上述目標容器具體也可以是一個在物理上隔離的硬體環境；比如，上述目標容器具體可以是一個在物理上隔離的物理晶片，可以將可信應用程式中的受保護碼隔離載入在該物理晶片中，來對上述受保護碼進行安全防護。
其中，需要強調的是，搭建TEE所採用的TEE搭建技術，在本說明書中不進行特別限定，本領域技術人員可以基於實際的開發需求來靈活的選擇。不難理解的是，上述目標容器的具體形態，通常也取決於本領域技術人員所採用的TEE搭建技術；亦即，上述目標容器最終是一個隔離的軟體環境，還是一個隔離的硬體環境，取決於本領域技術人員所採用的TEE搭建技術；例如，如果本領域技術人員採用Intel的SGX技術來搭建TEE，則上述目標容器是一個以CPU作為底層硬體支撐，且僅能由CPU進行存取的隔離的軟體環境(即Enclave程式)。
上述遠端接收對象，具體是指可信應用程式中的受保護碼的執行結果的遠端資料使用方；例如，在實際應用中，上述遠端接收對象可以是一個獨立的可信主機、可信系統；或者，也可以是一個在區塊鏈上部署的智慧型合約。
在以下實施例中，將以基於Intel的SGX技術來搭建TEE為例進行說明；其中，需要強調的是，以基於Intel的SGX技術來搭建TEE為例，僅為示意性的；顯而易見地，在實際應用中，顯然也可以採用其它的TEE搭建技術，來搭建TEE；比如，還可以採用諸如ARM的TrustZone技術，在本說明書中不在進行一一列舉。
在本說明書中，可信應用程式的軟體發展者，可以基於Intel的SGX技術，來創建作為TEE的Enclave程式，並將可信應用程式中的受保護碼隔離載入在該目標容器中。
需要說明的是，基於SGX技術創建Enclave程式，以及將受保護碼隔離載入在該目標容器中的具體實現過程，在本說明書中不再進行詳細說明，本領域技術護人員在將本說明書的技術方案付諸實現時，可以參考相關技術中的記載。
對於隔離載入在該Enclave程式中的受保護碼，通常稱之為該可信應用程式的可信區(Trusted Part)；而其它未被隔離載入在Enclave程式中的碼,則稱之為該可信應用程式的非可信區(Untrusted Part)。
其中，對於隔離載入在上述Enclave程式中的受保護碼，至少可以包括待執行碼和目標函數兩部分；
上述待執行碼，即為執行結果需要發送給遠端接收對象進行可信計算的受保護碼；亦即，可信應用程式需要透過可信證明技術，向遠端接收對象證明上述待執行碼的執行結果為可信資料。而上述目標函數，具體用於為上述目標容器產生公鑰和私鑰。
在SGX技術中，可信應用程式向遠端接收對象發起對受保護碼的執行結果的遠端證明，通常是透過與部署的IAS伺服器進行互動來完成的。
而本說明書中，可以不再利用SGX技術中現有的遠端證明機制，透過與IAS伺服器進行互動，來向遠端接收對象發起對受保護碼的執行結果的遠端證明，而是僅利用SGX技術中現有的遠端證明機制，向遠端接收對象發起一次對在Enclave程式內部獨立產生的公私鑰對的遠端證明，而後可以在上述公私鑰對的遠端證明通過後，基於上述公私鑰對，來便捷向遠端接收對象發起對受保護碼的執行結果的遠端證明，而不再需要與IAS進行互動。
在初始狀態下，可信應用程式的非可信區，可以透過ECALL的方式，呼叫隔離載入在該Enclave程式中的受保護碼中的目標函數，在Enclave程式內部產生一對公鑰以及私鑰。
其中，需要說明的是，非可信區透過ECALL的方式，針對隔離載入在該Enclave程式中的受保護碼中的目標函數的呼叫，可以在執行受保護碼中的待執行碼時即時地呼叫，也可以基於一定的呼叫週期來週期性地呼叫。
例如，在一種實現方式中，非可信區在接收到針對受保護碼中的待執行碼的執行指令時，可以即時回應該執行指令，立即透過ECALL的方式，呼叫隔離載入在該Enclave程式中的受保護碼中的目標函數，在Enclave內部產生一對公鑰和私鑰。
在另一種實現方式中，也可以為非可信區預先設定一個呼叫週期，使得非可信區可以基於該呼叫週期，來週期性呼叫隔離載入在該Enclave程式中的受保護碼中的目標函數，在Enclave程式內部產生一對公鑰和私鑰。透過這種方式，可以定時的對Enclave程式的公鑰和私鑰進行更新。
一方面，對於產生的私鑰，可以由處理器在Enclave程式內部進行加密處理(密鑰由處理器持有)，並由處理器為加密後的私鑰設置解密策略，然後將加密後的私鑰進行持有化儲存。
其中，基於SGX技術，針對加密後的資訊的解密策略，通常包括keypolicy-MRENCLAVE(以下簡稱MRENCLAVE策略)和keypolicy-MRSIGNER(以下簡稱MRSIGNER)兩種策略。
所謂MRENCLAVE策略，是指僅僅可被目前的ENCLAVE解密；而所謂MRSIGNER策略，是指可以被同一個開發者開發和簽署的所有ENCLAVE進行解密。
由於採用MRSIGNER策略，需要信任開發者；因此，對於獲取到開發者的私鑰的惡意者而言，透過開發惡意的ENCLAVE，並基於掌握的開發者的私鑰對該惡意的ENCLAVE進行簽署，就可以透過該惡意的ENCLAVE對加密後的私鑰進行解密，從而導致加密後的私鑰的明文資料洩露。
基於此，在本說明書中，處理器在為加密後的私鑰設置解密策略時，可以將解密策略設置為MRENCLAVE策略；亦即，僅目前的ENCLAVE具有對持久化儲存的加密後的私鑰進行解密的權限。
透過這種方式，可以確保即便是軟體發展者也無法獲取到ENCLAVE獨立產生的私鑰，從而可以顯著提升私鑰的安全等級。
另一方面，對於產生的公鑰，可以由可信執行程式的可信區透過IAS伺服器，向遠端接受對象發起針對該公鑰的遠端證明，並在該公鑰通過遠端證明時，將產生的該公鑰發送至遠端接收對象，由遠端接收對象進行持久化儲存。
基於SGX技術，可信執行程式的可信區，向遠端接受對象發起針對該公鑰的遠端證明時，首先可以基於產生的公鑰或者公鑰的hash值，創建一個作為遠端證明憑證的Quote；
例如，基於SGX技術，上述Quote通常是由Enclave和一個特殊的Quote Enclave進行內部互動，由Quote Enclave來創建完成的。其中，由Quote Enclave為Enclave創建用於遠端證明的Quote的具體實施過程，在本說明書中不在進行詳述，本領域技術人員在將本說明書的技術方案輔助時間時，可以參考相關技術中的技術。
在本說明書中，最終創建完成的Quote，透過可以包括EPID簽名、產生的公鑰或者公鑰的hash值(即需要遠端證明的userdata)、MRENCLAVE標識、處理器的EPID 標識等資訊。
亦即，最終創建完成的Quote，是針對產生的公鑰或者公鑰的hash值(即需要遠端證明的userdata)、MRENCLAVE標識、處理器的EPID 標識等資訊整體進行EPID簽名後得到的資訊。
其中，MRENCLAVE標識，通常為Enclave碼的hash值，用於唯一標識一個Enclave。EPID 標識，也稱之為basename，用於匿名標識一個處理器。而EPID簽名，是Intel的SGX技術採用的一種可以保持匿名的群簽名技術，在本說明書中對於EPID簽名的簽名處理過程，以及EPID簽名的簽名驗證過程，不再進行詳述，本領域技術人員可以參考相關技術中的記載。
在本說明書中，當產生了作為遠端證明憑證的Quote之後，可信執行程式的可信區，可以將該Quote發送給IAS伺服器進行遠端驗證。而IAS伺服器接收到該Quote之後，可以對該Quote的EPID簽名進行驗證，然後基於IAS伺服器持有的私鑰，對該Quote和針對該Quote的驗證結果整體進行簽名處理，產生對應的AVR(Attestation Verification Report，證明驗證報告)。
亦即，在本說明書中，上述AVR通常可以包括上述Quote、Quote驗證結果和IAS簽名等資訊。
在本說明書中，IAS伺服器可以將產生的AVR返回給可信執行程式的可信區，可信執行程式的可信區在接收到IAS伺服器返回的AVR後，可以將該AVR以及透過呼叫上述目標函數產生的公鑰，進一步發送給遠端接收對象。
或者，可信執行程式的可信區也可以將該AVR以及透過呼叫上述目標函數產生的公鑰，進一步發送給可信執行程式的非可信區，由上述非可信區將該AVR以及透過呼叫上述目標函數產生的公鑰，進一步發送給遠端接收對象。
而遠端接收對象在接收到可信執行程式的可信區發送的AVR之後，首先可以對AVR的狀態進行驗證；比如驗證AVR中的狀態欄位的取值是否為指示該AVR狀態正常的特定值；當AVR的狀態驗證通過之後，可以基於IAS伺服器持有的私鑰對應的公鑰，對該AVR的IAS簽名進行驗證；如果簽名驗證通過，此時可以進一步針對該AVR中攜帶的Quote中的公鑰或者公鑰的hash值、MRENCLAVE標識、處理器的EPID 標識等資訊進行驗證。
其中，對Quote中的公鑰或者公鑰的hash值進行的驗證，即為驗證Quote中的公鑰或者公鑰的hash值，與可信執行程式的可信區發送的公鑰是否匹配的過程；比如，如果Quote中攜帶的是公鑰的hash值，則可以進一步計算可信執行程式的可信區發送的公鑰的hash值，然後將計算出的hash值，與Quote中攜帶的公鑰的hash值進行匹配；如果二者匹配，則可以確認驗證通過。
其中，對Quote中的MRENCLAVE標識和處理器的EPID等資訊進行的驗證，即為驗證與MRENCLAVE標識對應Enclave，以及驗證與處理器的EPID對應的處理器是否可信的過程。
在實現時，Enclave的開發者可以透過開源Enclave碼來證明Enclave碼中不包含惡意程式碼，而遠端接收對象的管理員，可以對開源的Enclave碼進行安全審計，為遠端接收對象設置MRENCLAVE白名單。同樣，也可以按照實際需求，為遠端接收對象設置EPID 標識白名單。從而，遠端接收對象在對Quote中的MRENCLAVE標識和處理器的EPID標識等資訊進行驗證時，可以透過將Quote中的MRENCLAVE標識與MRENCLAVE白名單進行匹配，以及將Quote中的處理器的EPID標識與EPID 標識白名單進行匹配，來確認與MRENCLAVE標識對應Enclave，以及與處理器的EPID對應的處理器是否可信。
請繼續參見圖2，當AVR的IAS簽名；以及該AVR中攜帶的Quote中的公鑰或者公鑰的hash值、MRENCLAVE標識、處理器的EPID 標識等資訊均驗證通過之後，遠端接收對象可以將可信執行程式的可信區發送的透過呼叫上述目標函數產生的上述公鑰，以及對應的MRENCLAVE和EPID在本地進行持久化儲存。
亦即，將與呼叫上述目標函數產生的上述公鑰對應的MRENCLAVE作為可信程式標識，將與上述公鑰對應的EPID作為可信硬體標識，與上述公鑰一起進行持久化儲存。
在本說明書，當上述遠端接收對象將透過呼叫上述目標函數產生的上述公鑰在其本地進行持久化儲存之後，後續上述可信應用程式可以不再需要與IAS伺服器進行互動，來發起針對上述待執行碼的執行結果的遠端證明，而是直接透過呼叫上述目標函數創建的上述公私鑰對，來便捷向遠端接收對象發起對受保護碼的執行結果的遠端證明。
具體地，當隔離載入在上述Enclave中的待執行碼執行完畢，上述Enclave可以對已經持久化儲存的加密後的私鑰進行解密(只有該Enclave具有解密權限)，並基於解密出的私鑰，對該待的執行結果進行簽名處理。
其中，需要說明的是，實際應用中，上述執行結果除了可以包括上述待執行碼在執行完畢後的輸出結果以外，也可以引入其它的資訊；即可以根據實際的業務需求，將上述待執行碼的輸出結果以外的其它資訊也作為執行結果的一部分進行簽名處理，然後發起遠端認證；例如，在一個例子中，可以將上述待執行碼在執行時的輸入資料(比如，待執行碼在執行時輸入的執行參數)，也作為上述執行結果的一部分，進行簽名處理。
而可信應用程式的非可信區，可以獲取由上述Enclave簽名處理後的執行結果，將該執行結果直接發送給遠端接收對象，發起針對該執行結果的遠端證明。
當然，在實際應用中，也可以由可信應用程式的可信區，直接將簽名處理後的上述執行結果發送給遠端接收對象，發起針對該執行結果的遠端證明。
而遠端接收對象在接收到該執行結果後，可以基於在本地持久化儲存的上述公鑰(即呼叫上述目標函數產生的公鑰)，基於該公鑰對該執行結果的簽名進行驗證；如果該簽名驗證通過，則可以直接認定該執行結果為，在可信的處理器上創建的可信的Enclave所產生的可信資料；此時針對上述待執行碼的執行結果的遠端證明完成。
透過這種方式，在向遠端接收對象對上述待執行碼的執行結果進行遠端證明時，可以不再需要與IAS伺服器進行互動，從而可以更加便捷的完成遠端證明。
在以上技術方案中，一方面，由於用於遠端證明的公私鑰對在作為可信執行環境的目標容器中自主產生，不再由軟體提供商來產生；並且，持久化儲存的加密後的私鑰，被設置了僅由該目標容器進行解密的解密策略；因此，即便是軟體發展者也無法獲取到產生的私鑰，從而可以顯著提升私鑰的安全等級；
另一方面，由於可信應用程式僅需要透過第三方遠端證明服務端，向遠端接收對象發起一次針對自主產生的公鑰的遠端證明，並在該公鑰通過遠端證明之後，後續就可以直接使用產生的私鑰對受保護碼中的待執行碼的執行結果進行簽名，並將簽名後的執行結果發送給遠端接收對象完成針對該執行結果的遠端證明，而不再需要透過第三方遠端證明服務端來向遠端接收對象發起針對該執行結果的遠端證明；因此，可以不再需要與第三方遠端證明服務端進行頻繁的互動，就可以基於自主產生的公私鑰對就可以便捷的向遠端接收對象證明該執行結果為可信資料。
與上述方法實施例相對應，本說明書還提供了一種可信應用程式的遠端證明裝置的實施例。本說明書的可信應用程式的遠端證明裝置的實施例可以應用在電子設備上。裝置實施例可以透過軟體來實現，也可以透過硬體或者軟硬體結合的方式來實現。以軟體實現為例，作為一個邏輯意義上的裝置，是透過其所在電子設備的處理器將非易失性記憶體中對應的電腦程式指令讀取到記憶體中運行形成的。從硬體層面而言，如圖2所示，為本說明書的可信應用程式的遠端證明裝置所在電子設備的一種硬體結構圖，除了圖2所示的處理器、記憶體、網路介面、以及非易失性記憶體之外，實施例中裝置所在的電子設備通常根據該電子設備的實際功能，還可以包括其他硬體，對此不再贅述。
圖3是本說明書一示例性實施例示出的一種可信應用程式的遠端證明裝置的方塊圖。
請參考圖3，所述可信應用程式的遠端證明裝置30可以應用在前述圖2所示的電子設備中，其中，所述可信應用程式中的受保護碼被隔離載入在作為可信執行環境的目標容器中，所述受保護碼包括待執行碼，和用於產生私鑰以及公鑰的目標函數；
所述裝置30包括：
產生模組301，呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰，並對產生的私鑰進行加密，以及對加密後的私鑰進行持久化儲存，其中，加密的所述私鑰被設置了僅由所述目標容器進行解密的解密策略；
證明模組302，透過第三方遠端證明服務端向遠端接收對象發起針對所述公鑰的遠端證明，並在所述公鑰透過遠端證明時，將所述公鑰發送至所述遠端接收對象進行持久化儲存；
獲取模組303，獲取所述待執行碼的執行結果，其中，所述執行結果由所述目標容器基於解密出的所述私鑰進行了簽名處理；
驗證模組304，將所述執行結果發送至所述遠端接收對象，以由所述遠端接收對象基於儲存的所述公鑰對所述執行結果的簽名進行驗證，來確認所述執行結果是否為可信資料。
在本實施例中，所述產生模組301：
回應於所述待執行碼的執行指令，呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰；或者
基於預設的呼叫週期，週期性呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰。
在本實施例中，所述證明模組302：
基於產生的所述公鑰創建遠端證明憑證；
將所述遠端證明憑證發送至所述第三方遠端證明服務端，以由所述遠端證明服務端對所述遠端證明憑證進行驗證；
獲取所述遠端證明服務端返回的驗證結果，其中，所述驗證結果由所述遠端證明服務端基於持有的私鑰進行了簽名處理；
將所述驗證結果以及產生的所述公鑰發送至所述遠端接收對象，以由所述遠端接收對象至少基於所述第三方遠端證明服務端的公鑰對所述驗證結果的簽名進行驗證，並在所述簽名驗證通過後，將產生的所述公鑰在所述遠端接收對象本地進行持久化儲存。
在本實施例中，所述可信執行環境為基於SGX技術搭建的可信執行環境；所述目標容器為SGX技術中的Enclave程式，其中，加密後的所述私鑰的解密策略被設置為keypolicy-MRENCLAVE策略。
在本實施例中，所述遠端接收對象為發布至區塊鏈的智慧型合約。
上述裝置中各個模組的功能和作用的實現過程具體詳見上述方法中對應步驟的實現過程，在此不再贅述。
對於裝置實施例而言，由於其基本對應於方法實施例，所以相關之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中，所述作為分離部件說明的模組可以是或者也可以不是物理上分開的，作為模組顯示的部件可以是或者也可以不是物理模組，即可以位於一個地方，或者也可以分布到多個網路模組上。可以根據實際的需要選擇其中的部分或者全部模組來實現本說明書方案的目的。本領域普通技術人員在不付出創造性勞動的情況下，即可以理解並實施。
上述實施例闡明的系統、裝置、模組或模組，具體可以由電腦晶片或實體實現，或者由具有某種功能的產品來實現。一種典型的實現設備為電腦，電腦的具體形式可以是個人電腦、膝上型電腦、蜂巢式電話、相機電話、智慧型電話、個人數位助理、媒體播放機、導航設備、電子郵件收發設備、遊戲控制台、平板電腦、可穿戴設備或者這些設備中的任意幾種設備的組合。
與上述方法實施例相對應，本說明書還提供了一種電子設備的實施例。該電子設備包括：處理器以及用於儲存機器可執行指令的記憶體，其中，處理器和記憶體通常透過內部總線相互連接。在其他可能的實現方式中，所述設備還可能包括外部介面，以能夠與其他設備或者部件進行通訊。
在本實施例中，所述可信應用程式中的受保護碼被隔離載入在作為可信執行環境的目標容器中，其中，所述受保護碼包括待執行碼，和用於產生私鑰以及公鑰的目標函數；
透過讀取並執行所述記憶體儲存的與可信應用程式的遠端證明的控制邏輯對應的機器可執行指令，所述處理器被致使：
呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰，並對產生的私鑰進行加密，以及對加密後的私鑰進行持久化儲存，其中，加密的所述私鑰被設置了僅由所述目標容器進行解密的解密策略；
透過第三方遠端證明服務端向遠端接收對象發起針對所述公鑰的遠端證明，並在所述公鑰透過遠端證明時，將所述公鑰發送至所述遠端接收對象進行持久化儲存；
獲取所述待執行碼的執行結果，其中，所述執行結果由所述目標容器基於解密出的所述私鑰進行了簽名處理；
將所述執行結果發送至所述遠端接收對象，以由所述遠端接收對象基於儲存的所述公鑰對所述執行結果的簽名進行驗證，來確認所述執行結果是否為可信資料。
在本實施例中，透過讀取並執行所述記憶體儲存的與可信應用程式的遠端證明的控制邏輯對應的機器可執行指令，所述處理器被致使：
回應於所述待執行碼的執行指令，呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰；或者
基於預設的呼叫週期，週期性呼叫所述目標函數在所述目標容器中產生私鑰以及公鑰。
在本實施例中，透過讀取並執行所述記憶體儲存的與可信應用程式的遠端證明的控制邏輯對應的機器可執行指令，所述處理器被致使：
基於產生的所述公鑰創建遠端證明憑證；
將所述遠端證明憑證發送至所述第三方遠端證明服務端，以由所述遠端證明服務端對所述遠端證明憑證進行驗證；
獲取所述遠端證明服務端返回的驗證結果，其中，所述驗證結果由所述遠端證明服務端基於持有的私鑰進行了簽名處理；
將所述驗證結果以及產生的所述公鑰發送至所述遠端接收對象，以由所述遠端接收對象至少基於所述第三方遠端證明服務端的公鑰對所述驗證結果的簽名進行驗證，並在所述簽名驗證通過後，將產生的所述公鑰在所述遠端接收對象本地進行持久化儲存。
本領域技術人員在考慮說明書及實踐這裡揭示的發明後，將容易想到本說明書的其它實施方案。本說明書旨在涵蓋本說明書的任何變型、用途或者適應性變化，這些變型、用途或者適應性變化遵循本說明書的一般性原理並包括本說明書未揭示的本技術領域中的公知常識或慣用技術手段。說明書和實施例僅被視為示例性的，本說明書的真正範圍和精神由下面的申請專利範圍來指出。
應當理解的是，本說明書並不局限於上面已經描述並在圖式中示出的精確結構，並且可以在不脫離其範圍進行各種修改和改變。本說明書的範圍僅由所附的申請專利範圍來限制。
以上所述僅為本說明書的較佳實施例而已，並不用來限制本說明書，凡在本說明書的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本說明書保護的範圍之內。In practical applications, you can usually achieve security protection for these protected codes by building a TEE (Trusted Execution Environment, trusted execution environment) and isolating the protected codes in trusted applications in TEE.
Among them, when building a TEE, you can usually use the processor at the bottom of the device as hardware support to build a container that can only be accessed by the processor as a trusted execution environment, and use the The protected code is loaded into the container in isolation to isolate and protect the protected code in the container.
For example, taking Intel’s SGX (Software Guard Extensions) technology to build TEE as an example, based on SGX technology, the CPU of the device is usually used as a hardware support to create a program called Enclave as a protection container, The code that needs to be protected is isolated and loaded into the Enclave program to protect it from attacks.
In some scenarios, if the execution result of the protected code in the above trusted application needs to participate in the remote trusted computing, the trusted application needs to send the execution result of the above protected code to the remote In addition to receiving objects, it is usually necessary to prove the execution results of these protected codes to the remote receiving object based on the remote certification technology, without revealing the protected codes, as trusted materials.
For example, in a scenario, it is assumed that a smart contract deployed on a blockchain needs to use the execution result of a protected code in a trusted application as input data to perform trusted calculation on the blockchain; in this case Next, since the trusted application is not a node on the chain, it is an untrusted party for the smart contract; therefore, the trusted application is sending the execution result of the protected code to the smart contract deployed on the blockchain At that time, it is necessary to rely on the remote certification technology to prove to the smart contract that the execution result of these protected codes is trusted data (ie, on-chain certification) without revealing the protected codes.
Based on the current remote certification technology, when a trusted application initiates remote certification of specific data to a remote receiving object, it usually needs to rely on a third-party remote certification server to complete.
For example, still taking the remote certification mechanism in Intel's SGX technology as an example, based on the SGX technology, Intel will provide a third-party IAS (intel attestation service) server for remote certification. Isolate the execution result of the protected code loaded in the Enclave. If you need to participate in the trusted computing, the trusted application can interact with the IAS server, and initiate a request for the protected code to the remote receiving object through the IAS server. The remote authentication of the execution result proves to the remote receiving object that the execution result of the protected code is trusted material.
Because reliance on the third-party remote certification server to complete the remote certification requires frequent interaction with the third-party remote certification server, a more convenient remote certification mechanism is needed.
Based on this, this specification proposes a remote certification scheme based on the public and private key pair independently generated by the container as a trusted execution environment to conveniently initiate the execution result of the protected code to the remote receiving object.
During implementation, software developers of trusted applications can develop TEE target containers (such as Enclave programs in SGX technology) based on specific TEE building technologies (such as Intel’s SGX technology), and The protected code in the trusted application is loaded into the target container in isolation.
Among them, in this solution, the protected code that is loaded into the target container in isolation may include the code to be executed whose execution result needs to be remotely certified by the remote receiver, and the target used to generate the private key and public key Functions (essentially special codes that generate private keys and public keys).
Further, the trusted application can call the target function in the protected code loaded in the target container to generate a pair of public and private keys in the target container;
On the one hand, the generated private key can also be encrypted in the target container, where when the generated private key is encrypted in the target container, the encrypted private key can be set to be decrypted only by the target container Decryption strategy (that is, only the target container has decryption authority); then, the processor stores the encrypted private key persistently.
On the other hand, for the generated public key, you can use a third-party remote certification server to initiate remote certification of the public key to the remote recipient, and when the public key passes the remote certification, the generated The public key is sent to the remote receiving object, and the remote receiving object performs persistent storage.
Subsequently, when the execution of the code to be executed is completed, the target container may decrypt the encrypted private key and sign the execution result of the code to be executed based on the private key. The trusted application program can obtain the execution result signed and processed by the above target container, and send the execution result to the remote receiving object to initiate a remote certification for the execution result.
After receiving the execution result sent by the trusted application, the remote receiving object may verify the signature of the execution result based on the stored public key to determine whether the execution result is trusted data.
In the above technical solution, on the one hand, since the public and private key pair for remote certification is generated autonomously in the target container as a trusted execution environment, it is no longer generated by the software provider; and, the encrypted The private key is set with a decryption strategy that only the target container decrypts; therefore, even the software developer cannot obtain the generated private key, which can significantly improve the security level of the private key;
On the other hand, since the trusted application only needs to pass a third-party remote certification server, it initiates a remote certification of the publicly generated public key to the remote receiving object, and after the public key passes the remote certification, the subsequent You can directly use the generated private key to sign the execution result of the code to be executed in the protected code, and send the signed execution result to the remote receiving object to complete the remote certification of the execution result, without the need Through the third-party remote certification server to initiate remote certification of the execution result to the remote receiving object; therefore, it is no longer necessary to interact frequently with the third-party remote certification server, and it can be based on the publicly generated private key You can easily prove to the remote receiving object that the execution result is credible data.
The following describes the specification through specific embodiments and specific application scenarios.
Please refer to FIG. 1. FIG. 1 is a remote certification method for a trusted application provided by an embodiment of this specification. The method is applied to a trusted application. The protected code in the trusted application is isolated and loaded as In the target container of the trusted execution environment, wherein the protected code includes the code to be executed, and a target function for generating a private key and a public key, the method performs the following steps:
Step 102: Call the target function to generate a private key and a public key in the target container, encrypt the generated private key, and persistently store the encrypted private key, wherein the encrypted private key A decryption strategy that is only decrypted by the target container is set;
Step 104: A third-party remote certification server initiates remote certification of the public key to the remote receiving object, and sends the public key to the remote when the public key passes the remote certification Receive objects for persistent storage;
Step 106: Obtain the execution result of the code to be executed, wherein the execution result is signed by the target container based on the decrypted private key;
Step 108: Send the execution result to the remote receiving object, so that the remote receiving object verifies the signature of the execution result based on the stored public key to confirm whether the execution result is Credible information.
The above-mentioned trusted applications include applications developed by software developers that can provide trusted services to third parties. The code in the trusted applications usually includes protected parts and is not protected.
The above target container refers to a specific TEE construction technology based on this specification to build an isolated and safe operating environment that can provide security protection for the protected code in the trusted application.
Among them, in practical applications, the above target container may be an isolated software environment supported by the processor as the underlying hardware and can only be accessed by the processor; for example, taking TEE using Intel’s SGX technology as an example, The above target container may specifically be an Enclave program in the SGX technology. Usually, the protected code in the trusted application program is loaded into the Enclave program in isolation to protect the protected code.
Of course, in practical applications, it is not excluded that the above target container can also be a physically isolated hardware environment; for example, the above target container can be a physically isolated physical chip, which can be a trusted application The protected code in is isolated and loaded into the physical chip to protect the above protected code.
Among them, it should be emphasized that the TEE building technology used for building TEE is not particularly limited in this specification, and those skilled in the art can flexibly choose based on actual development needs. It is not difficult to understand that the specific shape of the above target container usually also depends on the TEE construction technology adopted by those skilled in the art; that is, the above target container is ultimately an isolated software environment or an isolated hardware environment, Depends on the TEE construction technology adopted by the person skilled in the art; for example, if the person skilled in the art uses Intel's SGX technology to build the TEE, the above target container is a CPU as the underlying hardware support, and can only be stored by the CPU The isolated software environment (ie Enclave program).
The above-mentioned remote receiving object specifically refers to a remote data user of the execution result of the protected code in the trusted application; for example, in practical applications, the above-mentioned remote receiving object may be an independent trusted host, Letter system; or, it can be a smart contract deployed on the blockchain.
In the following embodiments, the TEE based on Intel's SGX technology will be used as an example for explanation. Among them, it should be emphasized that the TEE based on Intel's SGX technology as an example is only schematic; obviously, in In practical applications, it is obvious that other TEE building technologies can also be used to build TEE; for example, TrustZone technology such as ARM can also be used, which will not be enumerated in this manual.
In this manual, software developers of trusted applications can create Enclave programs as TEE based on Intel's SGX technology, and load protected codes in trusted applications into the target container in isolation.
It should be noted that the specific implementation process of creating the Enclave program based on the SGX technology and loading the protected code in the target container is not described in detail in this specification. Those skilled in the art will When the technical solution is implemented, you can refer to the records in the related technologies.
The protected code that is loaded into the Enclave program in isolation is usually called the Trusted Part of the trusted application; other codes that are not loaded in the Enclave program in isolation are called The untrusted part of the trusted application.
Among them, the protected code that is loaded in the Enclave program above can include at least two parts of the code to be executed and the target function;
The above-mentioned code to be executed is the protected code that needs to be sent to the remote receiving object for trusted calculation as the execution result; that is, the trusted application needs to prove the above-mentioned code to be executed to the remote receiving object through a trusted certification technology. The execution result is credible information. The above target function is specifically used to generate a public key and a private key for the above target container.
In SGX technology, a trusted application initiates remote proof of the execution result of a protected code to a remote receiving object, usually through interaction with the deployed IAS server.
In this specification, you can no longer use the existing remote certification mechanism in SGX technology, and interact with the IAS server to initiate remote certification of the execution result of the protected code to the remote receiving object, but only use SGX The existing remote certification mechanism in the technology initiates a remote certification of the public and private key pair independently generated within the Enclave program to the remote receiving object, and then can be based on the public and private key after the remote certification of the public and private key pair is passed Yes, it is convenient to initiate remote certification of the execution result of the protected code to the remote receiving object, without the need to interact with the IAS.
In the initial state, the untrusted area of the trusted application can call the target function in the protected code loaded in the Enclave program by means of ECALL to generate a pair of public key and private key within the Enclave program. key.
Among them, it should be noted that the untrusted area can use ECALL to isolate the call of the target function loaded in the protected code in the Enclave program, and can execute the code to be executed in the protected code in real time. Calls can also be made periodically based on a certain call period.
For example, in one implementation, when the untrusted area receives the execution command for the code to be executed in the protected code, it can respond to the execution command in real time, and immediately call the isolation load in the Enclave program through the ECALL method. The objective function in the protected code in, generates a pair of public and private keys inside Enclave.
In another implementation manner, a call period may also be preset for the untrusted zone, so that the untrusted zone can periodically call the target loaded in the protected code in the Enclave program based on the call period The function generates a pair of public and private keys within the Enclave program. In this way, the public and private keys of the Enclave program can be updated regularly.
On the one hand, the generated private key can be encrypted by the processor within the Enclave program (the key is held by the processor), and the processor sets the decryption strategy for the encrypted private key, and then the encrypted private key The key is held for storage.
Among them, based on SGX technology, the decryption strategy for encrypted information usually includes two strategies: keypolicy-MRENCLAVE (hereinafter referred to as MRENCLAVE strategy) and keypolicy-MRSIGNER (hereinafter referred to as MRSIGNER).
The so-called MRENCLAVE strategy means that it can only be decrypted by the current ENCLAVE; and the so-called MRSIGNER strategy means that it can be decrypted by all ENCLAVEs developed and signed by the same developer.
Because the MRSIGNER strategy is adopted, developers need to be trusted; therefore, for a malicious person who has obtained the developer’s private key, by developing a malicious ENCLAVE and signing the malicious ENCLAVE based on the master’s private key, the The encrypted private key can be decrypted through the malicious ENCLAVE, resulting in the leakage of the plaintext data of the encrypted private key.
Based on this, in this specification, when the processor sets the decryption strategy for the encrypted private key, the decryption strategy can be set to the MRENCLAVE strategy; that is, only the current ENCLAVE has the encrypted private key for persistent storage. Decryption authority.
In this way, it can be ensured that even software developers cannot obtain the private key independently generated by ENCLAVE, which can significantly improve the security level of the private key.
On the other hand, for the generated public key, the trusted area of the trusted execution program can initiate a remote certification of the public key to the remote recipient through the IAS server, and when the public key passes the remote certification , Send the generated public key to the remote receiving object, and the remote receiving object will be stored persistently.
Based on the SGX technology, the trusted zone of the trusted execution program, when initiating a remote certificate for the public key to the remote recipient, can first create a certificate as the remote certificate based on the generated public key or the hash value of the public key Quote;
For example, based on SGX technology, the above Quote is usually internally interacted by Enclave and a special Quote Enclave and created by Quote Enclave. Among them, the specific implementation process of creating a Quote for remote enclave by Quote Enclave will not be described in detail in this specification. Those skilled in the art can refer to technology.
In this specification, the finally created Quote will include information such as the EPID signature, the generated public key or the hash value of the public key (that is, userdata that requires remote certification), the MRENCLAVE logo, and the processor's EPID logo.
That is, the Quote that is finally created is the information obtained by signing the entire public key or hash value of the public key (userdata that requires remote certification), the MRENCLAVE logo, and the EPID logo of the processor.
Among them, the MRENCLAVE logo, usually the hash value of the Enclave code, is used to uniquely identify an Enclave. EPID identification, also known as basename, is used to anonymously identify a processor. The EPID signature is a group signature technology used by Intel’s SGX technology that can maintain anonymity. In this specification, the signature processing process of the EPID signature and the signature verification process of the EPID signature will not be described in detail. Those skilled in the art You can refer to the description in the related art.
In this specification, after the Quote as a remote certificate is generated, the trusted area of the trusted execution program can send the Quote to the IAS server for remote verification. After receiving the Quote, the IAS server can verify the Quote’s EPID signature, and then based on the private key held by the IAS server, perform a signature process on the Quote and the verification result for the Quote as a whole to generate the corresponding AVR (Attestation Verification Report, certification verification report).
That is, in this specification, the AVR may generally include information such as Quote, Quote verification result, and IAS signature.
In this specification, the IAS server can return the generated AVR to the trusted area of the trusted execution program. After receiving the AVR returned by the IAS server, the trusted area of the trusted execution program can use the AVR and call The public key generated by the above objective function is further sent to the remote receiving object.
Alternatively, the trusted area of the trusted execution program can also send the AVR and the public key generated by calling the above target function to the untrusted area of the trusted execution program, and the untrusted area The public key generated by calling the above objective function is further sent to the remote receiving object.
After receiving the AVR sent by the trusted area of the trusted execution program, the remote receiving object can first verify the status of the AVR; for example, to verify whether the value of the status field in the AVR is a specific indication that the AVR status is normal Value; after the AVR status verification is passed, the IAS signature of the AVR can be verified based on the public key corresponding to the private key held by the IAS server; if the signature verification is passed, the Quote carried in the AVR can be further targeted at this time The public key or the hash value of the public key, the MRENCLAVE logo, the processor's EPID logo, and other information for verification.
Among them, the verification of the public key or the hash value of the public key in Quote is the process of verifying whether the public key or the hash value of the public key in Quote matches the public key sent by the trusted area of the trusted execution program ; For example, if the hash value of the public key is carried in Quote, you can further calculate the hash value of the public key sent by the trusted area of the trusted execution program, and then compare the calculated hash value with the public key carried in Quote Match the hash value; if the two match, you can confirm the verification.
Among them, the verification of the MRENCLAVE logo in the Quote and the EPID of the processor is to verify the Enclave corresponding to the MRENCLAVE logo and the process of verifying whether the processor corresponding to the EPID of the processor is trusted.
During implementation, Enclave developers can prove that the Enclave code does not contain malicious code through the open source Enclave code, and the administrator of the remote receiving object can perform a security audit on the open source Enclave code and set MRENCLAVE for the remote receiving object whitelist. Similarly, you can also set up an EPID whitelist for remote receiving objects according to actual needs. Therefore, when the remote receiving object verifies the information such as the MRENCLAVE logo in Quote and the EPID logo of the processor, it can match the MRENCLAVE logo in Quote with the MRENCLAVE white list and the EPID logo of the processor in Quote Match the EPID ID white list to confirm whether the Enclave corresponding to the MRENCLAVE ID and the processor corresponding to the EPID of the processor are trusted.
Please continue to refer to Figure 2. When the IAS signature of the AVR; and the public key or the hash value of the Quote in the AVR, the MRENCLAVE logo, and the EPID logo of the processor are all verified, the remote receiving object can The above-mentioned public key generated by calling the above-mentioned target function and the corresponding MRENCLAVE and EPID sent by the trusted area of the trusted execution program and stored locally are persistently stored.
That is, the MRENCLAVE corresponding to the public key generated by calling the target function is used as a trusted program identifier, and the EPID corresponding to the public key is used as a trusted hardware identifier for persistent storage together with the public key.
In this specification, after the remote receiving object persists the local public key generated by calling the target function locally, the trusted application can no longer need to interact with the IAS server to initiate targeting The remote certification of the execution result of the code to be executed is to directly initiate the remote certification of the execution result of the protected code to the remote receiving object by directly calling the public-private key pair created by the target function.
Specifically, when the to-be-executed code loaded in the Enclave is isolated, the Enclave can decrypt the encrypted private key that has been persistently stored (only the Enclave has decryption authority), and based on the decrypted private key , Sign the processing of the pending execution result.
Among them, it should be noted that in practical applications, the above execution result may include other information besides the output result of the above-mentioned to-be-executed code after the execution is completed; that is, the above-mentioned to-be-executed code may be converted according to actual business needs Information other than the output result is also signed as part of the execution result, and then remote authentication is initiated; for example, in an example, the input data of the above code to be executed during execution (for example, the code to be executed is executed The execution parameters entered at the time) are also signed as part of the above execution results.
The untrusted area of the trusted application program can obtain the execution result processed by the above Enclave signature, send the execution result directly to the remote receiving object, and initiate a remote certification for the execution result.
Of course, in practical applications, the trusted area of the trusted application program may also directly send the above-mentioned execution result after signature processing to the remote receiving object to initiate remote certification for the execution result.
After receiving the execution result, the remote receiving object may verify the signature of the execution result based on the public key based on the public key stored locally (that is, the public key generated by calling the target function); if If the signature verification is passed, the execution result can be directly regarded as the trusted data generated by the trusted Enclave created on the trusted processor; at this time, the remote certification of the execution result of the code to be executed is completed.
In this way, when remotely certifying the execution result of the to-be-executed code to the remote receiving object, it is no longer necessary to interact with the IAS server, so that remote certification can be completed more conveniently.
In the above technical solution, on the one hand, since the public and private key pair for remote certification is generated autonomously in the target container as a trusted execution environment, it is no longer generated by the software provider; and, the encrypted The private key is set with a decryption strategy that only the target container decrypts; therefore, even the software developer cannot obtain the generated private key, which can significantly improve the security level of the private key;
On the other hand, since the trusted application only needs to pass a third-party remote certification server, it initiates a remote certification of the publicly generated public key to the remote receiving object, and after the public key passes the remote certification, the subsequent You can directly use the generated private key to sign the execution result of the code to be executed in the protected code, and send the signed execution result to the remote receiving object to complete the remote certification of the execution result, without the need Through the third-party remote certification server to initiate remote certification of the execution result to the remote receiving object; therefore, it is no longer necessary to interact frequently with the third-party remote certification server, and it can be based on the publicly generated private key You can easily prove to the remote receiving object that the execution result is credible data.
Corresponding to the above method embodiments, this specification also provides an embodiment of a remote certification device for trusted applications. The embodiment of the remote certification device of the trusted application program in this specification can be applied to an electronic device. The device embodiments can be implemented by software, or by hardware or a combination of hardware and software. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory through the processor of the electronic device in which it is located. From the hardware level, as shown in Figure 2, it is a hardware structure diagram of the electronic equipment where the remote certification device of the trusted application of this specification is located, except for the processor, memory, and network shown in Figure 2. In addition to the interface and the non-volatile memory, the electronic device in which the device is located in the embodiment generally may include other hardware according to the actual function of the electronic device, which will not be repeated here.
Fig. 3 is a block diagram of a remote certification device for a trusted application program according to an exemplary embodiment of the present specification.
Referring to FIG. 3, the remote certification device 30 of the trusted application can be applied to the electronic device shown in FIG. 2, wherein the protected code in the trusted application is isolated and loaded as In the target container of the letter execution environment, the protected code includes the code to be executed, and a target function for generating a private key and a public key;
The device 30 includes:
The generating module 301 calls the target function to generate a private key and a public key in the target container, encrypts the generated private key, and persists the encrypted private key for storage, wherein the encrypted The private key is set with a decryption strategy that is only decrypted by the target container;
The certification module 302 initiates remote certification of the public key to the remote receiving object through a third-party remote certification server, and sends the public key to the public key when the public key passes the remote certification Persistent storage of remote receiving objects;
The obtaining module 303 obtains the execution result of the code to be executed, wherein the execution result is signed by the target container based on the decrypted private key;
The verification module 304 sends the execution result to the remote receiving object, so that the remote receiving object verifies the signature of the execution result based on the stored public key to confirm the execution result Whether it is credible information.
In this embodiment, the generation module 301:
In response to the execution instruction of the code to be executed, calling the target function to generate a private key and a public key in the target container; or
Based on a preset call period, the target function is periodically called to generate a private key and a public key in the target container.
In this embodiment, the certification module 302:
Create a remote certificate based on the generated public key;
Sending the remote certificate to the third-party remote certificate server to verify the remote certificate by the remote certificate server;
Obtaining the verification result returned by the remote certification server, wherein the verification result is signed by the remote certification server based on the held private key;
Sending the verification result and the generated public key to the remote receiving object, so that the remote receiving object signs the verification result based at least on the public key of the third-party remote certification server Verification, and after the signature verification is passed, the generated public key is locally stored in the remote receiving object locally.
In this embodiment, the trusted execution environment is a trusted execution environment built based on SGX technology; the target container is the Enclave program in SGX technology, wherein the decryption strategy of the encrypted private key is set to keypolicy-MRENCLAVE strategy.
In this embodiment, the remote receiving object is a smart contract issued to the blockchain.
For the implementation process of the functions and functions of each module in the above device, please refer to the implementation process of the corresponding steps in the above method for details, which will not be repeated here.
For the device embodiment, since it basically corresponds to the method embodiment, the relevant part can be referred to the description of the method embodiment. The device embodiments described above are only schematic, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules , That is, it can be located in one place, or can be distributed to multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. Those of ordinary skill in the art can understand and implement without paying creative labor.
The system, device, module or module explained in the above embodiments may be implemented by a computer chip or entity, or by a product with a certain function. A typical implementation device is a computer, and the specific form of the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an e-mail sending and receiving device, a game Consoles, tablets, wearable devices, or any combination of these devices.
Corresponding to the above method embodiments, this specification also provides an embodiment of an electronic device. The electronic device includes a processor and a memory for storing machine executable instructions, wherein the processor and the memory are usually connected to each other through an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.
In this embodiment, the protected code in the trusted application program is isolated and loaded in a target container as a trusted execution environment, where the protected code includes the code to be executed, and is used to generate a private key And the objective function of the public key;
By reading and executing machine-executable instructions stored in the memory corresponding to the control logic of the remote certification of the trusted application, the processor is caused to:
Call the target function to generate a private key and a public key in the target container, encrypt the generated private key, and persistently store the encrypted private key, wherein the encrypted private key is set A decryption strategy for decryption by the target container only;
Initiate remote certification of the public key to the remote receiving object through a third-party remote certification server, and when the public key passes the remote certification, send the public key to the remote receiving object for Persistent storage;
Acquiring the execution result of the code to be executed, wherein the execution result is signed by the target container based on the decrypted private key;
Sending the execution result to the remote receiving object to verify the signature of the execution result based on the stored public key by the remote receiving object to confirm whether the execution result is a credible material .
In this embodiment, by reading and executing machine-executable instructions stored in the memory corresponding to the control logic of the remote certification of the trusted application, the processor is caused to:
In response to the execution instruction of the code to be executed, calling the target function to generate a private key and a public key in the target container; or
Based on a preset call period, the target function is periodically called to generate a private key and a public key in the target container.
In this embodiment, by reading and executing machine-executable instructions stored in the memory corresponding to the control logic of the remote certification of the trusted application, the processor is caused to:
Create a remote certificate based on the generated public key;
Sending the remote certificate to the third-party remote certificate server to verify the remote certificate by the remote certificate server;
Obtaining the verification result returned by the remote certification server, wherein the verification result is signed by the remote certification server based on the held private key;
Sending the verification result and the generated public key to the remote receiving object, so that the remote receiving object signs the verification result based at least on the public key of the third-party remote certification server Verification, and after the signature verification is passed, the generated public key is locally stored in the remote receiving object locally.
After considering the description and practicing the invention disclosed herein, those skilled in the art will easily think of other embodiments of the description. This specification is intended to cover any variations, uses, or adaptations of this specification. These variations, uses, or adaptations follow the general principles of this specification and include common knowledge or common technical means in the technical field not disclosed in this specification. . The description and examples are only to be considered exemplary, and the true scope and spirit of this description are indicated by the following patent application.
It should be understood that this specification is not limited to the precise structure that has been described above and shown in the drawings, and that various modifications and changes can be made without departing from its scope. The scope of this specification is limited only by the scope of the attached patent application.
The above are only the preferred embodiments of this specification and are not intended to limit this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification should be included in this specification Within the scope of protection.
