下面將參照圖式更詳細地描述本公開的示例性實施例。雖然圖式中顯示了本公開的示例性實施例，然而應當理解，可以以各種形式實現本公開而不應被這裏闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，並且能夠將本公開的範圍完整的傳達給本領域的技術人員。
本發明提供一種基於可信執行環境的應用程式啟動方案。在本發明的技術方案中，首先，對終端設備中的可信執行環境進行啟動，在可信執行環境已啟動的基礎上，可信執行環境可以向終端設備的其他應用程式提供可信的應用程式啟動及啟動驗證服務，從而保證其他應用程式的安全。
圖1示出了根據本發明一個實施例的可信執行環境的啟動系統100的示意圖。如圖1所示，系統100包括終端設備110和服務端120。應當指出，雖然圖1所示的系統100僅包括一個終端設備110和一個服務端120，但是，本領域技術人員可以理解，在實踐中，系統100可以包括任意數量的終端設備110和服務端120，本發明對系統100所包括的終端設備110、服務端120的數量均不做限制。
終端設備110具體可以實現為任意設備，例如手機、平板電腦、智慧可穿戴設備、智慧家電、車機、無人機等，但不限於此。如圖1所示，終端設備110中部署有可信執行環境（Trusted Execution Environment，簡稱TEE）和富執行環境（Rich Execution Environment，簡稱REE）。可信執行環境與富執行環境具有相互隔離的硬體、以及獨立的操作系統，用於滿足不同安全級別的應用程式的運行要求。可信執行環境與富執行環境的硬體隔離例如可以透過ARM TrustZone或C-SKY的安全擴展技術來實現，但不限於此。
富執行環境的操作系統可以是Android、iOS、RTOS實時操作系統等通用操作系統，該操作系統上可以運行對安全性要求不高的普通應用程式，例如即時通訊、拍照、天氣查詢等。可信執行環境的操作系統通常為一個封閉的、功能相對簡單的安全操作系統，在該操作系統上運行對安全性要求較高的可信應用程式，例如指紋識別、身分認證、電子支付、智慧鎖等。可信執行環境中的可信應用程式可以被富執行環境中的普通應用程式調用以實現相應功能。可信應用程式不可直接與外部（例如伺服器、其他終端設備、用戶等）進行通信，而需要以富執行環境中的普通應用程式為通信中轉，即，可信執行環境中的可信應用程式經由富執行環境中的普通應用程式來與外部進行通信。
服務端120可以是任意用於向終端設備110提供可信執行環境在線啟動服務的設備，例如物理伺服器、或部署於物理伺服器中的計算實例等，但不限於此。服務端120用於向終端設備110提供可信執行環境的在線啟動服務。在可信執行環境被啟動後，終端設備110才可以使用可信執行環境來處理和保護敏感資料。
在本發明的實施例中，可信執行環境包括啟動管理應用程式112，啟動管理應用程式112經由部署於富執行環境中的介面應用程式113與服務端120通信，用於對可信執行環境進行啟動。具體地，啟動管理應用程式112讀取終端設備標識，將終端設備標識經由介面應用程式113發送至服務端120。服務端120根據終端設備標識產生啟動碼，並且產生終端設備的可信身分標識和可信密鑰，將可信身分標識和可信密鑰與終端設備標識關聯儲存。可信身分標識是一個可以代表設備唯一性的字符串，其用於唯一標識終端設備110，且具備不可篡改、不可偽造、全球唯一的安全屬性。可信密鑰為根據可信身分標識透過特定演算法派生出來的字符串，其用於對與終端設備110相關的關鍵資訊進行加密。服務端120將可信身分標識、可信密鑰和啟動碼加密後產生啟動資訊，經由介面應用程式113將啟動資訊發送至啟動管理應用程式112。啟動管理應用程式112對啟動資訊進行解密，得出可信身分標識、可信密鑰和啟動碼後，將可信身分標識、可信密鑰和啟動碼加密儲存至安全儲存空間111。安全儲存空間111為用於儲存文件的指定空間，文件採用可信密鑰加密後儲存到該位置。在本發明的實施例中，安全儲存空間111能且僅能被啟動管理應用程式112訪問。在將可信身分標識、可信密鑰和啟動碼加密儲存至安全儲存空間111後，終端設備110的可信執行環境啟動完成。
富執行環境中的普通應用程式可以調用可信執行環境中的可信應用程式。當可信應用程式被調用時，該被調用的可信應用程式將進一步調用啟動管理應用程式112，以觸發可信執行環境的啟動驗證。啟動管理應用程式112從安全儲存空間111中讀取可信身分標識、可信密鑰和啟動碼，根據可信身分標識、可信密鑰和啟動碼來驗證可信執行環境是否啟動成功，隨後，將驗證結果返回給被普通應用程式調用的可信應用程式。若驗證啟動成功，則被調用的可信應用程式執行普通應用程式的調用，並將調用結果返回給普通應用程式。
例如，如圖1所示，富執行環境中的第一普通應用程式114為購物應用程式，第一可信應用程式115為電子支付應用程式。當用戶在第一普通應用程式114中選中某些商品，需要付款進行購買時，第一普通應用程式114調用第一可信應用程式115來實現電子支付功能。第一可信應用程式115被調用後，觸發啟動管理應用程式112進行可信執行環境的啟動驗證。啟動管理應用程式112從安全儲存空間111中讀取可信身分標識、可信密鑰和啟動碼，根據可信身分標識、可信密鑰和啟動碼來驗證可信執行環境是否啟動成功，並將驗證結果返回給第一可信應用程式。若驗證啟動成功，則第一可信應用程式115執行第一普通應用程式114的調用以實現電子支付功能，並將調用結果（是否支付成功）返回給第一普通應用程式114。
在可信執行環境已啟動的基礎上，可信執行環境可以向終端設備110的其他應用程式提供應用程式啟動及啟動驗證服務，從而保證其他應用程式的安全。圖2示出了根據本發明一個實施例的基於可信執行環境的應用程式啟動系統200的示意圖。如圖2所示，系統200包括終端設備110和服務端120，終端設備110中部署有可信執行環境和富執行環境，富執行環境中部署有第二普通應用程式116。在終端設備110的可信執行環境已啟動的基礎上，可以基於可信執行環境來啟動第二普通應用程式116。
服務端120進一步包括應用程式服務端122和認證服務端124。應用程式服務端122為向第二普通應用程式116提供方法及資料調用的服務端，其可以產生用於啟動第二普通應用程式116的使用權限資訊（例如生效時間、失效時間、可用次數等）。認證服務端124用於驗證終端設備110的身分，根據使用權限資訊來產生校驗資訊，以及對使用權限資訊、校驗資訊進行加密等。
具體地，第二普通應用程式116觸發啟動管理應用程式112來驗證可信執行環境是否啟動成功，在可信執行環境啟動成功的情况下，將終端設備的可信身分標識發送至應用程式服務端122。應用程式服務端122將可信身分標識發送至認證服務端124。認證服務端124對終端設備110的身分進行驗證，並將驗證結果返回給應用程式服務端122。在認證服務端124驗證通過的情况下，應用程式服務端122產生第二普通應用程式116的使用權限資訊，並將使用權限資訊發送至認證服務端124。認證服務端124根據使用權限資訊和可信身分標識來產生校驗資訊，將使用權限資訊和校驗資訊組合成註冊碼，獲取可信身分標識所對應的可信密鑰，採用可信密鑰對註冊碼進行加密，產生註冊資訊，並將加密後的註冊資訊依次經由應用程式服務端122、第二普通應用程式116發送至啟動管理應用程式112。啟動管理應用程式112從安全儲存空間111中獲取可信密鑰，採用可信密鑰對註冊資訊進行解密以得到註冊碼，並將註冊碼加密儲存至安全儲存空間111。在將註冊碼加密儲存至安全儲存空間111後，第二普通應用程式116啟動完成。
圖3示出了根據本發明一個實施例的可信執行環境的啟動方法300的流程圖。方法300在終端設備（例如前述終端設備110）的可信執行環境中執行，例如，由可信執行環境中的啟動管理應用程式112來執行。如圖3所示，方法300始於步驟S310。
在步驟S310中，將終端設備標識發送至服務端。
終端設備標識用於唯一標識一個終端設備。由於終端設備標識具有唯一性，因此，也可將其稱為設備指紋。終端設備標識例如可以是終端設備的MAC（Media Access Control）地址、CPU序列號、硬碟序列號等資訊，或者是對終端設備的MAC地址、CPU序列號等資訊進行加工處理所得到的計算結果等，但不限於此。本發明對終端設備標識的具體內容不做限制。根據一種實施例，透過調用相應的資料介面來獲取終端設備標識，該資料介面通常由終端設備的生産廠商提供。
具體地，步驟S310由可信執行環境中的啟動管理應用程式來執行。啟動管理應用程式112不可直接與服務端進行通信，而是經由富執行環境中的介面應用程式113來將終端設備標識發送至服務端。
根據一種實施例，除了將終端設備標識發送至服務端之外，還可以根據終端設備標識來產生認證碼，將認證碼一併發送至服務端，以便服務端對認證碼進行驗證，在認證碼驗證通過後，再根據終端設備標識來產生啟動碼。
根據一種實施例，認證碼包括預置密鑰、第一密文和第一映射值，其中，第一密文為採用預置密鑰對會話密鑰和終端設備標識進行加密所產生的密文，第一映射值為採用預設的映射函數對會話密鑰和終端設備標識進行映射所得到的值。根據一種實施例，預置密鑰是啟動管理應用程式112的配置資訊之一，相應地，預置密鑰的值可以從啟動管理應用程式的配置資訊中讀取。會話密鑰由終端設備產生，例如，由啟動管理應用程式112來產生。根據一種實施例，當啟動管理應用程式112與服務端通信時，啟動管理應用程式112將產生用於本次通信的令牌（Token），該令牌包括從配置資訊中讀取的預置密鑰和產生的會話密鑰。根據令牌中的預置密鑰和會話密鑰，可以確定第一密文，進而產生認證碼。本領域技術人員可以理解，除預置密鑰和會話密鑰之外，令牌中還可以包括其他資訊，例如啟動管理應用程式112的應用程式標識、啟動管理應用程式112的版本號、預置密鑰用途、預置密鑰類型等，本發明對令牌中所包括的具體資訊不做限制。
另外，需要說明的是，產生第一密文所採用的加密演算法，以及產生第一映射值所採用的映射函數均可以由本領域技術人員自行設置，本發明對此不做限制。例如，產生第一密文所採用的加密演算法可以是AES加密演算法，產生第一映射值所採用的映射函數可以是散列演算法，但不限於此。
在產生認證碼後，將認證碼和終端設備標識一併發送至服務端，以便服務端對認證碼進行驗證，從中恢復出會話密鑰，並保證認證碼和終端設備標識在傳輸過程中沒有被截獲或惡意篡改。根據一種實施例，服務端可以按照以下方法來對認證碼進行驗證：
從認證碼中讀取預置密鑰，採用預置密鑰來對認證碼中的第一密文進行解密，以得到會話密鑰和終端設備標識。隨後，採用預設的映射函數來計算會話密鑰和終端設備標識的第二映射值，若第二映射值與認證碼中的第一映射值一致，則認證碼驗證通過。
本領域技術人員可以理解，為了使服務端能夠對認證碼進行驗證，需要在終端設備與服務端之間公開某些演算法參數，例如產生第一密文所採用的加密演算法、產生第一映射值所採用的映射函數等。這些參數可以在終端設備向服務端傳輸終端設備標識與認證碼之前，由終端設備與服務端事先達成一致；也可以將這些參數作為認證碼的欄位，隨認證碼一同傳輸至服務端；等。本發明對終端設備與服務端同步演算法參數的具體方法不做限制。
表1示出了可信執行環境啟動過程中的認證碼AuthCode1的一個示例：
表1 預置金鑰 第一密文 第一映射值
Provisioning Key1 Provisioning_Key_Encrypt(Session Key+Dev_FP) Hash_Sha256(Session Key+Dev_FP)
表1中，預置密鑰為Provisioning Key1，第一密文為Provisioning_Key_Encrypt(Session Key + Dev_FP)，即，第一密文為採用預置密鑰Provisioning Key1來對會話密鑰Session Key和終端設備標識Dev_FP進行加密所得到的密文。第一映射值為Hash_Sha256(Session Key+Dev_FP)，即，第一映射值為採用SHA256演算法計算出的會話密鑰Session Key和終端設備標識Dev_FP的散列值。
本領域技術人員可以理解，在實踐中，除表1中所列的欄位外，認證碼AuthCode1還可以包括其他欄位，例如啟動管理應用程式112的應用程式標識、啟動管理應用程式112的版本號、預置密鑰用途、預置密鑰類型等，本發明對認證碼中所包括的欄位的數量及種類均不做限制。
在將表1所示的認證碼AuthCode1和終端設備標識Dev_FP發送至服務端後，服務端將對該認證碼進行驗證：首先，從認證碼AuthCode1中讀取預置密鑰Provisioning Key1。隨後，採用Provisioning Key1對第一密文Provisioning_Key_Encrypt (Session Key + Dev_FP)進行解密，以恢復出會話密鑰Session Key。最後，採用SHA256演算法來計算恢復出的會話密鑰Session Key和終端設備標識Dev_FP的散列值，若該散列值與AuthCode1中的第一映射值一致，則AuthCode1驗證成功。
隨後，在步驟S320中，接收服務端返回的啟動資訊，啟動資訊包括加密後的可信身分標識、可信密鑰和啟動碼，其中，可信身分標識、可信密鑰與終端設備標識相對應，啟動碼根據終端設備標識產生。
可信身分標識和可信密鑰由服務端產生。服務端產生可信身分標識和可信密鑰，並將可信身分標識和可信密鑰與終端設備標識關聯儲存。可信身分標識是一個可以代表設備唯一性的字符串，用於唯一標識一個終端設備，且其具備不可篡改、不可偽造、全球唯一的安全屬性。可信密鑰為根據可信身分標識透過特定演算法派生出來的字符串，其用於對與可信身分標識所對應的終端設備相關的關鍵資訊進行加密。
啟動碼根據終端設備標識產生，用於對終端設備的可信執行環境進行啟動。根據一種實施例，啟動碼包括可信執行環境的使用權限資訊和校驗資訊。
可信執行環境的使用權限資訊用於標記可信執行環境的使用權限。使用權限資訊例如可以包括生效時間、失效時間、可用次數等，但不限於此。當使用權限資訊包括生效時間、失效時間時，終端設備僅在生效時間~失效時間的時間範圍內能夠正常使用可信執行環境，在生效時間~失效時間的時間範圍之外，終端設備的可信執行環境處於未啟動狀態，可信執行環境不可用。當使用權限資訊包括可用次數時，終端設備僅可以在可用次數以內來調用可信執行環境，若終端設備調用可信執行環境的次數達到可用次數後，可信執行環境將處於未啟動狀態，可信執行環境不可用。本領域技術人員可以理解，使用權限資訊可以進行配置，其可以包括生效時間、失效時間、可用次數中的至少一項，也可以包括除生效時間、失效時間、可用次數之外的其他資訊，本發明對使用權限資訊所包括的具體內容不做限制。
校驗資訊用於對啟動碼進行校驗，以保證啟動碼沒有被非法篡改。根據一種實施例，校驗資訊包括採用可信密鑰對可信身分標識、使用權限資訊、終端設備標識進行加密所產生的密文。本發明對產生校驗資訊所採用的具體加密演算法不做限制，例如，產生校驗資訊所採用的加密演算法例如可以是HMAC（Hash-based Message Authentication Code）演算法，但不限於此。
表2示出了啟動碼ActiCode的一個示例：
表2 許可權資訊 校驗資訊
生效時間 失效時間 可用次數
Stime1 Etime1 Times1 HMAC(IDkey, Dev_FP + ID+Stime1+ Etime1+Times1)
表2中，使用權限資訊包括生效時間Stime1、失效時間Etime1和可用次數Times1。校驗資訊為HMAC(IDkey, Dev_FP + ID + Stime1 + Etime1 +Times1)，即，校驗資訊為基於HMAC演算法，採用可信密鑰IDkey對終端設備標識Dev_FP、可信身分標識ID、生效時間Stime1、失效時間Etime1和可用次數Times1進行加密所產生的消息摘要。
本領域技術人員可以理解，在實踐中，除表2中所列的欄位外，啟動碼ActiCode還可以包括其他欄位，例如採用可信密鑰IDkey對啟動碼ActiCode進行加密所採用的演算法、用於驗證可信密鑰IDkey是否被篡改的密鑰校驗值KCV（Key Checksum Value）、以及產生密鑰校驗值KCV的演算法，等等，本發明對啟動碼中所包括的欄位的數量及種類均不做限制。
在步驟S320中，啟動資訊包括加密後的可信身分標識、可信密鑰和啟動碼。根據一種實施例，啟動資訊可以按照以下步驟產生：採用可信密鑰對啟動碼進行加密，以產生啟動碼密文；採用會話密鑰對可信身分標識、可信密鑰、啟動碼密文進行加密，以產生啟動資訊。會話密鑰由終端設備與服務端事先確定，例如，會話密鑰可以在終端設備向服務端傳輸終端設備標識與認證碼之前，由終端設備與服務端事先達成一致；又例如，參見表1，會話密鑰Session Key可以隱含於認證碼AuthCode1中，傳遞至服務端；等。本發明對會話密鑰的產生及會話密鑰在終端設備與服務端之間的傳遞方法均不做限制。此外，產生啟動碼密文以及產生啟動資訊所採用的加密演算法可以是任意加密演算法，本發明對此亦不做限制。
以表1、表2為例，啟動資訊的產生步驟如下：首先，採用可信密鑰IDkey對啟動碼ActiCode進行加密，產生啟動碼密文ActiCode’。隨後，採用從認證碼AuthCode1中確定的會話密鑰Session Key來對可信身分標識ID、可信密鑰IDkey、啟動碼密文ActiCode’進行加密，產生啟動資訊。
在步驟S320接收到啟動資訊後，執行步驟S330。
在步驟S330中，對啟動資訊進行解密，以得到可信身分標識、可信密鑰和啟動碼。
對啟動資訊進行解密的過程與服務端加密產生啟動資訊的過程相反。根據一種實施例，按照以下步驟對啟動資訊進行解密：首先，採用會話密鑰對啟動資訊進行解密，以得到可信身分標識、可信密鑰和啟動碼密文；隨後，採用可信密鑰對啟動碼密文進行解密，以得到啟動碼。
以表2為例，啟動資訊的解密過程如下：首先，採用會話密鑰Session Key來對啟動資訊進行解密，以得到可信身分標識ID、可信密鑰IDkey、啟動碼密文ActiCode’。隨後，採用可信密鑰IDkey來對啟動碼密文ActiCode’進行解密，以得到啟動碼ActiCode。
在步驟S330得到可信身分標識、可信密鑰和啟動碼後，執行步驟S340。
在步驟340中，將可信身分標識、可信密鑰和啟動碼加密儲存至安全儲存空間。安全儲存空間中的資料只能被可信執行環境中的啟動管理應用程式112讀取，保證了其中的資料不會被非法獲取以及篡改。
根據一種實施例，在步驟S330中得到可信身分標識、可信密鑰和啟動碼後，不是直接將可信身分標識、可信密鑰和啟動碼直接加密儲存至安全儲存空間，而是先根據終端設備標識來驗證啟動碼，以保證啟動資訊在服務端與終端設備的傳輸過程中沒有被非法篡改。在啟動碼驗證通過後，再將可信身分標識、可信密鑰和啟動碼加密儲存至安全儲存空間。
根據一種實施例，可以按照以下步驟來驗證啟動碼：採用可信密鑰對可信身分標識、使用權限資訊、終端設備標識進行加密，產生第二密文；若第二密文與啟動碼中的校驗資訊一致，則啟動碼驗證通過。
以表2為例，啟動碼ActiCode的驗證過程如下：獲取終端設備標識Dev_FP（例如透過終端設備的生産廠商所提供的資料介面獲取）。基於HMAC演算法，採用可信密鑰IDkey對終端設備標識Dev_FP、可信身分標識ID、生效時間Stime1、失效時間Etime1和可用次數Times1進行加密，產生第二密文。若第二密文與啟動碼中的校驗資訊一致，則啟動碼驗證通過。否則，則驗證未通過。
在將可信身分標識、可信密鑰和啟動碼加密儲存至安全儲存空間111後，終端設備的可信執行環境啟動完成。安全儲存空間111中的可信身分標識、可信密鑰、啟動碼均僅能由可信執行環境中的啟動管理應用程式112讀取。
圖4示出了根據本發明一個實施例的可信執行環境的啟動過程的示意圖。圖4中，安全儲存空間111、啟動管理應用程式112、介面應用程式113均位於終端設備110中，啟動管理應用程式112為可信執行環境中的可信應用程式，介面應用程式113為富執行環境中的普通應用程式。
在步驟S401中，用戶透過介面應用程式113來觸發啟動管理應用程式112進行可信執行環境的啟動驗證。
在步驟S402和S403中，啟動管理應用程式112從安全儲存空間111中讀取可信執行環境的啟動碼ActiCode，對ActiCode進行驗證，並在步驟S404中將驗證結果發送給介面應用程式113。若安全儲存空間111中未儲存有ActiCode或啟動管理應用程式112對ActiCode驗證失敗，則在步驟S404中，啟動管理應用程式112將向介面應用程式113返回可信執行環境未啟動的結果。隨後，執行步驟S405。
在步驟S405中，介面應用程式113觸發啟動管理應用程式112來對可信執行環境進行啟動。
在步驟S406中，啟動管理應用程式112透過終端設備廠商提供的介面獲取終端設備標識Dev_FP，獲取預置密鑰Provisioning Key1，並產生會話密鑰Session Key。
在步驟S407中，啟動管理應用程式112根據終端設備標識Dev_FP來產生認證碼AuthCode1，如前述表1所示，AuthCode1包括預置密鑰Provisioning Key1、第一密文Provisioning_Key_Encrypt(Session Key + Dev_FP)、以及第一映射值Hash_Sha256(Session Key + Dev_FP)。
在步驟S408中，啟動管理應用程式112將終端設備標識Dev_FP和認證碼AuthCode1發送至介面應用程式113。
在步驟S409中，介面應用程式113將終端設備標識Dev_FP和認證碼AuthCode1發送至服務端120。
在步驟S410中，服務端120對認證碼AuthCode1進行驗證：首先，從認證碼AuthCode1中讀取預置密鑰Provisioning Key1。隨後，採用Provisioning Key1對第一密文Provisioning_Key_Encrypt(Session Key + Dev_FP)進行解密，以恢復出會話密鑰Session Key。最後，採用SHA256演算法來計算恢復出的會話密鑰Session Key和終端設備標識Dev_FP的散列值，若該散列值與AuthCode1中的第一映射值一致，則AuthCode1驗證成功。隨後，執行步驟S411。
在步驟S411中，服務端120產生可信身分標識ID和可信密鑰IDkey，並將可信身分標識ID和可信密鑰IDkey與終端設備標識Dev_FP關聯儲存。
在步驟S412中，服務端120根據終端設備標識Dev_FP產生啟動碼ActiCode，如表2所示，ActiCode包括生效時間Stime1、失效時間Etime1、可用次數Times1和校驗資訊HMAC(IDkey, Dev_FP + ID + Stime1 + Etime1 +Times1)。採用可信密鑰IDkey對啟動碼ActiCode進行加密，產生啟動碼密文ActiCode’；採用會話密鑰Session Key來對可信身分標識ID、可信密鑰IDkey、啟動碼密文ActiCode’進行加密，產生啟動資訊。
在步驟S413中，服務端120將啟動資訊發送至介面應用程式113。
在步驟S414中，介面應用程式113將啟動資訊發送至啟動管理應用程式112。
在步驟S415中，啟動管理應用程式112採用會話密鑰Session Key來對啟動資訊進行解密，以得到可信身分標識ID、可信密鑰IDkey、啟動碼密文ActiCode’。隨後，採用可信密鑰IDkey來對啟動碼密文ActiCode’進行解密，以得到啟動碼ActiCode。
在步驟S416中，啟動管理應用程式112透過終端設備的生産廠商所提供的資料介面獲取終端設備標識Dev_FP。基於HMAC演算法，採用可信密鑰IDkey對終端設備標識Dev_FP、可信身分標識ID、生效時間Stime1、失效時間Etime1和可用次數Times1進行加密，產生第二密文。若第二密文與啟動碼中的校驗資訊一致，則啟動碼驗證通過，執行步驟S417。
在步驟S417和S418中，啟動管理應用程式112將可信身分標識ID、可信密鑰IDkey和啟動碼ActiCode加密儲存至安全儲存空間111，可信執行環境啟動成功。
在步驟S419中，啟動管理應用程式112將可信執行環境啟動成功的結果反饋至介面應用程式113。
圖5示出了根據本發明一個實施例的可信執行環境的啟動方法500的流程圖。方法500在服務端（例如圖1所示的服務端120）中執行，與前述在終端設備中執行的方法300相對應。如圖5所示，方法500始於步驟S510。
在步驟S510中，接收終端設備發送的終端設備標識。
由於啟動管理應用程式112不可直接與服務端進行通信，而需要經由富執行環境中的介面應用程式113來與服務端進行通信，因此，在步驟S510中，服務端從介面應用程式113處接收終端設備標識。
根據一種實施例，在步驟S510中，除了接收終端設備標識之外，還接收終端設備發送的認證碼，認證碼根據終端設備標識產生。對認證碼進行驗證，在認證碼驗證通過後，再執行步驟S520，根據終端設備標識產生啟動碼。
根據一種實施例，認證碼包括預置密鑰、第一密文和第一映射值，其中，第一密文為採用預置密鑰對會話密鑰和終端設備標識進行加密所產生的密文，第一映射值為採用預設的映射函數對會話密鑰和終端設備標識進行映射所得到的值。相應地，服務端可以按照以下方法來對認證碼進行驗證：從認證碼中讀取預置密鑰，採用預置密鑰來對認證碼中的第一密文進行解密，以得到會話密鑰和終端設備標識。隨後，採用預設的映射函數來計算會話密鑰和終端設備標識的第二映射值，若第二映射值與認證碼中的第一映射值一致，則認證碼驗證通過。
認證碼的產生及驗證的具體實施步驟可以參考前述步驟S310的相關描述，此處不再贅述。
隨後，在步驟S520中，產生與終端設備標識相對應的可信身分標識和可信密鑰，以及根據終端設備標識產生啟動碼。
可信身分標識用於唯一標識一個終端設備，且其具備不可篡改、不可偽造、全球唯一的安全屬性。可信密鑰為與可信身分標識相對應的密鑰，其用於對關鍵資訊進行加密。服務端可以按照任意演算法來產生可信身分標識和可信密鑰，本發明對產生可信身分標識和可信密鑰所採用的具體演算法不做限制。在產生可信身分標識和可信密鑰後，將可信身分標識和可信密鑰關聯儲存。
啟動碼根據終端設備標識產生，用於對終端設備的可信執行環境進行啟動。根據一種實施例，啟動碼包括可信執行環境的使用權限資訊和校驗資訊。
可信執行環境的使用權限資訊用於標記可信執行環境的使用權限。使用權限資訊例如可以包括生效時間、失效時間、可用次數等，但不限於此。
校驗資訊用於對啟動碼進行校驗，以保證啟動碼沒有被非法篡改。根據一種實施例，校驗資訊包括採用可信密鑰對可信身分標識、使用權限資訊、終端設備標識進行加密所產生的密文。本發明對產生校驗資訊所採用的具體加密演算法不做限制，例如，產生校驗資訊所採用的加密演算法例如可以是HMAC演算法，但不限於此。啟動碼ActiCode的一個示例可以參考前述表2，此處不再贅述。
隨後，在步驟S530中，對可信身分標識、可信密鑰和啟動碼進行加密以產生啟動資訊。
根據一種實施例，採用可信密鑰對啟動碼進行加密，以產生啟動碼密文；採用會話密鑰對可信身分標識、可信密鑰、啟動碼密文進行加密，以產生啟動資訊。啟動資訊的具體產生步驟可以參考前述對步驟S320的相關描述，此處不再贅述。
隨後，在步驟S540中，將啟動資訊發送至終端設備，以便終端設備：對啟動資訊進行解密以得到可信身分標識、可信密鑰和啟動碼，以及將可信身分標識、可信密鑰和啟動碼加密儲存至安全儲存空間。
步驟S540的具體實施過程可以參考前述步驟S330、340的相關描述，此處不再贅述。
富執行環境中的普通應用程式可以調用可信執行環境中的可信應用程式。當可信應用程式被調用時，該被調用的可信應用程式將進一步調用啟動管理應用程式112，以觸發可信執行環境的啟動驗證。
圖6示出了根據本發明一個實施例的可信執行環境的啟動驗證方法600的流程圖。方法600在終端設備的可信執行環境中執行，例如，由可信執行環境中的啟動管理應用程式112來執行。如圖6所示，方法600始於步驟S610。
在步驟S610中，獲取可信身分標識、可信密鑰和可信執行環境的啟動碼，啟動碼包括可信執行環境的使用權限資訊和校驗資訊，校驗資訊包括採用可信密鑰對可信身分標識、使用權限資訊、終端設備標識進行加密所產生的密文。
根據一種實施例，啟動管理應用程式112從安全儲存空間111中讀取可信身分標識ID、可信密鑰IDkey和可信執行環境的啟動碼ActiCode。啟動碼ActiCode進一步包括使用權限資訊，例如，如表2所示，啟動碼ActiCode，包括生效時間Stime1、失效時間Etime1和可用次數Times1三項使用權限資訊，以及校驗資訊HMAC(IDkey, Dev_FP + ID + Stime1 + Etime1 +Times1)。校驗資訊為基於HMAC演算法，採用可信密鑰IDkey對終端設備標識Dev_FP、可信身分標識ID、生效時間Stime1、失效時間Etime1和可用次數Times1進行加密所產生的消息摘要。
隨後，在步驟S620中，獲取終端設備標識，採用可信密鑰對可信身分標識、使用權限資訊、終端設備標識進行加密，產生第三密文。
根據一種實施例，透過終端設備的生産廠商所提供的資料介面獲取終端設備標識Dev_FP，基於HMAC演算法，採用可信密鑰IDkey對可信身分標識ID、生效時間Stime1、失效時間Etime1、可用次數Times1和終端設備標識Dev_FP進行加密，產生第三密文。
隨後，在步驟S630中，若第三密文與校驗資訊一致，且終端設備當前的使用環境與使用權限資訊匹配，則可信執行環境啟動成功。
例如，使用權限資訊包括生效時間、失效時間和可用次數，相應地，終端設備當前的使用環境包括時間、已用次數等資訊。若終端設備當前的時間在生效時間~失效時間的範圍內，且已用次數小於等於可用次數，則終端設備當前的使用環境與使用權限資訊匹配。
圖7示出了根據本發明一個實施例的可信執行環境的啟動驗證過程的示意圖。圖7中，安全儲存空間111、啟動管理應用程式112、第一可信應用程式115、第一普通應用程式114均位於終端設備110中，啟動管理應用程式112、第一可信應用程式115為可信執行環境中的可信應用程式，第一普通應用程式114為富執行環境中的普通應用程式。
在步驟S701中，第一普通應用程式114向第一可信應用程式115發起調用請求。
在步驟S702中，第一可信應用程式115觸發啟動管理應用程式112進行可信執行環境的啟動驗證。
在步驟S703和S704中，啟動管理應用程式112從安全儲存空間111中讀取可信身分標識ID、可信密鑰IDkey和可信執行環境的啟動碼ActiCode。如表2所示，ActiCode包括生效時間Stime1、失效時間Etime1、可用次數Times1和校驗資訊HMAC(IDkey, Dev_FP + ID + Stime1 + Etime1 + Times1)。
在步驟S705中，啟動管理應用程式112透過終端設備的生産廠商所提供的資料介面獲取終端設備標識Dev_FP。基於HMAC演算法，採用可信密鑰IDkey對可信身分標識ID、生效時間Stime1、失效時間Etime1、可用次數Times1和終端設備標識Dev_FP進行加密，產生第三密文。若第三密文與啟動碼中的校驗資訊一致，則啟動碼驗證通過，可信執行環境已啟動。
在步驟S706中，啟動管理應用程式112將可信執行環境已啟動的結果發送至第一可信應用程式115。
在步驟S707中，第一可信應用程式115執行第一普通應用程式114所請求的調用。
在步驟S708中，第一可信應用程式115將調用結果返回給第一普通應用程式114。
在可信執行環境已啟動的基礎上，可信執行環境可以向終端設備110的其他應用程式提供應用程式啟動及啟動驗證服務，從而保證其他應用程式的安全。
圖8示出了根據本發明一個實施例的基於可信執行環境的應用程式啟動方法800的流程圖。方法800在終端設備的可信執行環境中執行，例如，由可信執行環境中的啟動管理應用程式112來執行。方法200可用於啟動富執行環境中的普通應用程式，例如圖2中所示的第二普通應用程式116。如圖8所示，方法800始於步驟S810。
在步驟S810中，將終端設備的可信身分標識發送至服務端。
可信身分標識儲存於終端設備的安全儲存空間111中，其僅能被可信執行環境中的特定可信應用程式，例如啟動管理應用程式112讀取。啟動管理應用程式112獲取可信身分標識後，透過富執行環境中的待啟動的應用程式（例如圖2中的第二普通應用程式116）將可信身分標識發送至服務端120。
根據一種實施例，在將可信身分標識發送至服務端之前，需要先驗證可信執行環境是否啟動成功；在可信執行環境啟動成功的情况下，再將終端設備的可信身分標識發送至服務端。
具體地，可以按照前述方法600所示的步驟來驗證可信執行環境是否啟動成功。若可信執行環境啟動成功，則可信執行環境可用，可以基於可信執行環境來對待啟動的應用程式進行啟動。若可信執行環境啟動失敗，則可信執行環境不可用，這時，需要先執行前述方法300來啟動可信執行環境，在可信執行環境啟動後，才可以執行本發明的方法800。
根據一種實施例，步驟S810除了將可信身分標識發送至服務端之外，還根據可信身分標識產生認證碼，將認證碼與可信身分標識一併發送至服務端，以便服務端對認證碼進行驗證，在認證碼驗證通過後，根據可信身分標識來產生註冊碼。
根據一種實施例，認證碼包括預置密鑰、第四密文和第三映射值，其中，第四密文為採用預置密鑰對可信身分標識進行加密所產生的密文，第三映射值為採用預設的映射函數對可信身分標識進行映射所得到的值。根據一種實施例，預置密鑰是啟動管理應用程式112的配置資訊之一，相應地，預置密鑰的值可以從啟動管理應用程式的配置資訊中讀取。根據一種實施例，當啟動管理應用程式112與服務端通信時，啟動管理應用程式112將產生用於本次通信的令牌（Token），該令牌包括從配置資訊中讀取的預置密鑰。根據令牌中的預置密鑰，可以確定第四密文，進而產生認證碼。本領域技術人員可以理解，除預置密鑰和會話密鑰之外，令牌中還可以包括其他資訊，例如啟動管理應用程式112的應用程式標識、啟動管理應用程式112的版本號、預置密鑰用途、預置密鑰類型等，本發明對令牌中所包括的具體資訊不做限制。
另外，需要說明的是，產生第四密文所採用的加密演算法，以及產生第三映射值所採用的映射函數均可以由本領域技術人員自行設置，本發明對此不做限制。例如，產生第四密文所採用的加密演算法可以是AES加密演算法，產生第三映射值所採用的映射函數可以是散列演算法，但不限於此。
在產生認證碼後，將認證碼和可信身分標識一併發送至服務端，以便服務端對認證碼進行驗證，保證認證碼和可信身分標識在傳輸過程中沒有被篡改。根據一種實施例，服務端可以按照以下方法來對認證碼進行驗證：
從認證碼中讀取預置密鑰，採用預置密鑰對第四密文進行解密以得到可信身分標識，採用預設的映射函數來計算可信身分標識的第四映射值，若第四映射值與認證碼中的第三映射值一致，則認證碼驗證通過。
表3示出了基於可信執行環境的應用程式啟動過程中的認證碼AuthCode2的一個示例：
表3 預置金鑰 第四密文 第三映射值
Provisioning Key2 Provisioning_Key_Encrypt(ID) Hash_Sha256(ID)
表3中，預置密鑰為Provisioning Key2，第四密文為Provisioning_Key_Encrypt(ID)，即，第四密文為採用預置密鑰Provisioning Key2來對可信身分標識ID進行加密所得到的密文。第三映射值為Hash_Sha256(ID)，即，第三映射值為採用SHA256演算法計算出的可信身分標識ID的散列值。
本領域技術人員可以理解，在實踐中，除表3中所列的欄位外，認證碼AuthCode2還可以包括其他欄位，例如啟動管理應用程式112的應用程式標識、啟動管理應用程式112的版本號、預置密鑰用途、預置密鑰類型等，本發明對認證碼中所包括的欄位的數量及種類均不做限制。
在將表3中所示的認證碼AuthCode2發送至服務端後，服務端將對該認證碼進行驗證：首先，從認證碼AuthCode2中讀取預置密鑰Provisioning Key2。隨後，採用Provisioning Key2對第四密文Provisioning_Key_Encrypt(ID)進行解密，以得到可信身分標識ID。最後，採用SHA256演算法來計算可信身分標識ID的散列值，若該散列值與AuthCode2中的第三映射值一致，則AuthCode2驗證成功。
隨後，在步驟S820中，接收服務端返回的註冊資訊，註冊資訊包括採用可信身分標識所對應的可信密鑰加密後的註冊碼，註冊碼根據可信身分標識產生。
註冊碼根據可信身分標識產生，用於對待啟動的應用程式進行啟動。根據一種實施例，註冊碼包括待啟動的應用程式的使用權限資訊和校驗資訊。
應用程式的使用權限資訊用於標記該應用程式的使用權限。使用權限資訊例如可以包括生效時間、失效時間、可用次數等，但不限於此。當使用權限資訊包括生效時間、失效時間時，用戶僅在生效時間~失效時間的時間範圍內能夠正常使用該應用程式，在生效時間~失效時間的時間範圍之外，該應用程式不可用。當使用權限資訊包括可用次數時，用戶僅可以在可用次數以內來使用該應用程式，若用戶使用該應用程式的次數達到可用次數後，該應用程式不再可用。本領域技術人員可以理解，使用權限資訊可以進行配置，其可以包括生效時間、失效時間、可用次數中的至少一項，也可以包括除生效時間、失效時間、可用次數之外的其他資訊，本發明對應用程式的使用權限資訊所包括的具體內容不做限制。
校驗資訊用於對註冊碼進行校驗，以保證註冊碼沒有被非法篡改。根據一種實施例，校驗資訊包括採用可信密鑰對可信身分標識和使用權限資訊進行加密所產生的密文。本發明對產生校驗資訊所採用的具體加密演算法不做限制，例如，產生校驗資訊所採用的加密演算法例如可以是HMAC（Hash-based Message Authentication Code）演算法，但不限於此。
表4示出了註冊碼License的一個示例：
表4 許可權資訊 校驗資訊
生效時間 失效時間 可用次數
Stime2 Etime2 Times2 HMAC(IDkey, ID + Stime2 + Etime2 +Times2)
表4中，應用程式的使用權限資訊包括生效時間Stime2、失效時間Etime2和可用次數Times2。校驗資訊為HMAC(IDkey, ID + Stime2 + Etime2 +Times2)，即，校驗資訊為基於HMAC演算法，採用可信密鑰IDkey對可信身分標識ID、生效時間Stime2、失效時間Etime2和可用次數Times2進行加密所產生的消息摘要。
在步驟S820中，註冊資訊包括採用可信身分標識所對應的可信密鑰加密後的註冊碼。即，服務端首先確定可信身分標識所對應的可信密鑰，隨後，採用可信密鑰對註冊碼進行加密，產生註冊資訊。
需要說明的是，方法800中將註冊碼加密產生註冊資訊的過程與方法300中將啟動碼加密產生啟動資訊的過程略有不同。在方法300中，啟動碼經過了可信密鑰、會話密鑰的雙重加密；在方法800中，註冊碼僅經過可信密鑰的單重加密。這是因為，在方法300中，可信密鑰為初次產生，需要將可信密鑰隨啟動碼一同發送至終端設備。而為了保證可信密鑰不被截獲、篡改，在採用可信密鑰對啟動碼進行加密後，還需要採用會話密鑰來對可信密鑰加密，使可信密鑰對外部不可見。在方法800中，可信密鑰未進行傳輸，而僅分別儲存於終端設備和服務端，即使其他設備監聽到終端設備與服務端之間傳輸的註冊資訊，由於無法獲取到可信密鑰，其也無法對註冊資訊進行解密以獲取註冊碼。因此，在方法800中，僅採用可信密鑰對註冊碼進行單重加密即可保證註冊碼的安全，無需再用會話密鑰進行二次加密。
隨後，在步驟S830中，採用可信密鑰對註冊資訊進行解密，以得到註冊碼。
隨後，在步驟S840中，將註冊碼加密儲存至安全儲存空間。安全儲存空間中的資料只能被可信執行環境中的啟動管理應用程式112讀取，保證了其中的資料不會被非法獲取以及篡改。
根據一種實施例，在步驟S830中得到註冊碼後，不是直接將註冊碼加密儲存至安全儲存空間，而是先根據可信身分標識來驗證註冊碼，以保證註冊資訊在服務端與終端設備的傳輸過程中沒有被非法篡改。在註冊碼驗證通過後，再將註冊碼加密儲存至安全儲存空間。
根據一種實施例，可以按照以下步驟來驗證註冊碼：採用可信密鑰對可信身分標識、使用權限資訊進行加密，產生第五密文；若第五密文與註冊碼中的校驗資訊一致，則註冊碼驗證通過。
以表4為例，註冊碼License的驗證過程如下：獲取可信密鑰IDkey，基於HMAC演算法，採用可信密鑰IDkey對可信身分標識ID、生效時間Stime2、失效時間Etime2和可用次數Times2進行加密，產生第五密文。若第五密文與註冊碼中的校驗資訊一致，則註冊碼驗證通過。否則，則驗證未通過。
在將待啟動的應用程式的註冊碼加密儲存至安全儲存空間111後，待啟動的應用程式啟動完成。安全儲存空間111中的註冊碼僅能由可信執行環境中的啟動管理應用程式112讀取。
圖9示出了根據本發明一個實施例的基於可信執行環境的應用程式啟動過程的示意圖。圖9中，安全儲存空間111、啟動管理應用程式112、第二普通應用程式116位於終端設備中，啟動管理應用程式112為可信執行環境中的可信應用程式，第二普通應用程式116為富執行環境中的待啟動的應用程式。應用程式服務端122、認證服務端124位於服務端。應用程式服務端122用於向第二普通應用程式116提供方法及資料調用，產生第二普通應用程式116的使用權限資訊（例如生效時間、失效時間、可用次數等）。認證服務端124用於驗證終端設備110的身分，以及對相關資料進行加密等。
在步驟S901中，第二普通應用程式116向啟動管理應用程式112發起初始化可信執行環境的請求。啟動管理應用程式112基於該請求，對可信執行環境進行啟動驗證。若可信執行環境啟動驗證成功，則執行步驟S902。
在步驟S902和S903中，啟動管理應用程式112從安全儲存空間111中讀取可信身分標識ID和可信密鑰IDkey。
在步驟S904中，啟動管理應用程式112根據可信身分標識ID來產生認證碼AuthCode2，如前述表3所示，AuthCode2包括預置密鑰Provisioning Key2，第四密文Provisioning_Key_Encrypt(ID)和第三映射值Hash_Sha256(ID)。
在步驟S905中，啟動管理應用程式112將可信身分標識ID和認證碼AuthCode2發送至第二普通應用程式116。
在步驟S906中，第二普通應用程式116將可信身分標識ID和認證碼AuthCode2發送至應用程式服務端122。
在步驟S907中，應用程式服務端122將可信身分標識ID和認證碼AuthCode2發送至認證服務端124。
在步驟S908中，認證服務端124對認證碼AuthCode2進行驗證：首先，從認證碼AuthCode2中讀取預置密鑰Provisioning Key2。隨後，採用Provisioning Key2對第四密文Provisioning_Key_Encrypt(ID)進行解密，以得到可信身分標識ID。最後，採用SHA256演算法來計算可信身分標識ID的散列值，若該散列值與AuthCode2中的第三映射值一致，則AuthCode2驗證成功。
在步驟S909中，認證服務端124將認證碼AuthCode2驗證成功的結果返回給應用程式服務端122。
在步驟S910中，應用程式服務端122產生第二普通應用程式116的使用權限資訊，參見表4，使用權限資訊包括生效時間Stime2、失效時間Etime2和可用次數Times2。
在步驟S911中，應用程式服務端122將產生的使用權限資訊發送至認證服務端124。
在步驟S912中，認證服務端124產生校驗資訊，參見表4，校驗資訊為HMAC(IDkey, ID + Stime2 + Etime2 + Times2)。隨後，將使用權限資訊和校驗資訊組合形成註冊碼License。查找可信身分標識ID所對應的可信密鑰IDkey，採用IDkey對License進行加密，產生註冊資訊。
在步驟S913~S915中，認證服務端124依次經過應用程式服務端122、第二普通應用程式116，將註冊資訊發送至啟動管理應用程式112。
在步驟S916中，啟動管理應用程式112採用可信密鑰IDkey對註冊資訊進行解密，得到註冊碼License。採用可信密鑰IDkey對可信身分標識ID、生效時間Stime2、失效時間Etime2和可用次數Times2進行加密，產生第五密文。若第五密文與License中的校驗資訊一致，則註冊碼驗證通過，執行步驟S917。
在步驟S917和S918中，啟動管理應用程式112將註冊碼License加密儲存至安全儲存空間111，第二普通應用程式116啟動成功。
在步驟S919中，啟動管理應用程式112將第二普通應用程式116啟動成功的結果反饋至第二普通應用程式116。
圖10示出了根據本發明一個實施例的基於可信執行環境的應用程式啟動方法1000的流程圖。方法100在服務端（例如圖2所示的服務端120）中執行，與前述在終端設備中執行的方法800相對應，適於對待啟動的應用程式（例如圖2所示的第二普通應用程式116）進行啟動。
根據一種實施例，服務端進一步包括應用程式服務端（例如圖2所示的應用程式服務端122）和認證服務端（例如圖2所示的認證服務端124），應用程式服務端和認證服務端分工協作，以實現基於可信執行環境的應用程式啟動。應用程式服務端可與待啟動的應用程式直接通信，用於向待啟動的應用程式提供方法及資料調用，產生待啟動的應用程式的使用權限資訊（例如生效時間、失效時間、可用次數等）。認證服務端通常不與待啟動的應用程式直接通信，用於驗證終端設備110的身分，以及對相關資料進行加密等。
如圖10所示，方法1000始於步驟S1010。
在步驟S1010中，接收終端設備發送的可信身分標識。
可信身分標識儲存於終端設備的安全儲存空間111中，其僅能被可信執行環境中的特定可信應用程式，例如啟動管理應用程式112讀取。啟動管理應用程式112獲取可信身分標識後，透過待啟動的應用程式發送至應用程式服務端。相應地，應用程式服務端接收待啟動的應用程式發來的可信身分標識。
根據一種實施例，在步驟S1010中，除了接收可信身分標識之外，還接受終端設備發送的認證碼，認證碼根據可信身分標識產生。對認證碼進行驗證，在認證碼驗證通過後，再執行步驟S520，根據可信身分標識產生註冊碼。
根據一種實施例，應用程式服務端122在接收到第二普通應用程式116發來的可信身分標識和認證碼後，將可信身分標識和認證碼轉發至認證服務端124，由認證服務端124來對認證碼進行驗證。認證碼的具體驗證過程可以參考前述步驟S810的相關描述，此處不再贅述。
隨後，在步驟S1020中，根據可信身分標識產生註冊碼。
根據一種實施例，註冊碼包括待啟動的應用程式的使用權限資訊和校驗資訊，其中，使用權限資訊用於標記該應用程式的使用權限，其例如可以包括生效時間、失效時間、可用次數等，但不限於此。校驗資訊用於對註冊碼進行校驗，以保證註冊碼沒有被非法篡改。根據一種實施例，校驗資訊包括採用可信密鑰對可信身分標識和使用權限資訊進行加密所產生的密文。
根據一種實施例，註冊碼中的使用權限資訊由應用程式服務端122產生。應用程式服務端122產生使用權限資訊後，將使用權限資訊發送至認證服務端124，由認證服務端124來產生校驗資訊。使用權限資訊、校驗資訊的具體產生過程可以參考前述步驟S820的相關描述，此處不再贅述。
隨後，在步驟S1030中，採用可信身分標識所對應的可信密鑰來加密註冊碼，以產生註冊資訊。
根據一種實施例，步驟S1030由認證服務端124執行。
隨後，在步驟S1040中，將註冊資訊發送至終端設備，以便終端設備：採用可信密鑰對註冊資訊進行解密，以得到註冊碼；以及將註冊碼加密儲存至安全儲存空間。
在步驟S1040中，認證服務端124依次經過應用程式端122、待啟動的應用程式，將註冊資訊發送至終端設備中的啟動管理應用程式112。啟動管理應用程式112採用可信密鑰對註冊資訊進行解密，以得到註冊碼；以及將註冊碼加密儲存至安全儲存空間。
步驟S1040的具體實施過程可以參考前述步驟S830、S840的相關描述，此處不再贅述。
當用戶使用某一應用程式時，將會觸發該應用程式的啟動驗證。只有當驗證該應用程式啟動成功時，用戶才可以使用該應用程式；若驗證該應用程式啟動失敗，則該應用程式對用戶不可用。
圖11示出了根據本發明一個實施例的基於可信執行環境的應用程式啟動驗證方法1100的流程圖。方法1100在終端設備的可信執行環境中執行，例如，由可信執行環境中的啟動管理應用程式112來執行。如圖11所示，方法1100始於步驟S1110。
在步驟S1110中，獲取可信身分標識、可信密鑰和待驗證的應用程式的註冊碼，註冊碼包括使用權限資訊和校驗資訊，校驗資訊為採用可信密鑰對可信身分標識、使用權限資訊進行加密所產生的密文。
根據一種實施例，啟動驗證應用程式112從安全儲存空間111中獲取可信身分標識、可信密鑰和待驗證的應用程式的註冊碼。
隨後，在步驟S1120中，採用可信密鑰對可信身分標識、使用權限資訊進行加密，產生第六密文。
隨後，在步驟S1130中，若第六密文與校驗資訊一致，則將註冊碼發送至待驗證的應用程式，以便該應用程式根據當前使用環境與使用權限資訊是否匹配來確定其是否啟動成功。
例如，使用權限資訊包括生效時間、失效時間和可用次數，相應地，該應用程式當前的使用環境包括時間、已用次數等資訊。若當前的時間在生效時間~失效時間的範圍內，且該應用程式的已用次數小於等於可用次數，則當前的使用環境與使用權限資訊匹配，該應用程式啟動成功。
圖12示出了根據本發明一個實施例的基於可信執行環境的應用程式啟動驗證過程的示意圖。圖12中，安全儲存空間111、啟動管理應用程式112、第二普通應用程式116均位於終端設備110中，啟動管理應用程式112為可信執行環境中的可信應用程式，第二普通應用程式116為富執行環境中的普通應用程式。
在步驟S1201中，當用戶使用第二普通應用程式116時，第二普通應用程式116向啟動管理應用程式112發起啟動驗證請求。
在步驟S1202和S1203中，啟動管理應用程式112從安全儲存空間111中獲取可信身分標識ID、可信密鑰IDkey和可信執行環境的啟動碼ActiCode。
在步驟S1204中，啟動管理應用程式112根據可信身分標識ID、可信密鑰IDkey和啟動碼ActiCode來驗證可信執行環境是否啟動成功。在可信執行環境啟動成功的情况下，繼續執行步驟S1205。
在步驟S1205和S1206中，啟動管理應用程式112從安全儲存空間111中獲取註冊碼License。參見表4，License包括生效時間Stime2、失效時間Etime2、可用次數Times2和校驗資訊HMAC(IDkey, ID + Stime2 + Etime2 +Times2)。
在步驟S1207中，啟動管理應用程式112採用可信密鑰IDkey對可信身分標識ID、生效時間Stime2、失效時間Etime2和可用次數Times2進行加密，產生第六密文。若第六密文與License中的校驗資訊一致，則執行步驟S1208。
在步驟S1208中，啟動管理應用程式112將註冊碼發送至第二普通應用程式116。
在步驟S1209中，第二普通應用程式116獲取當前使用環境，當前使用環境包括當前時間和第二普通應用程式116的已用次數。讀取註冊碼中的生效時間Stime2、失效時間Etime2、可用次數Times2。判斷當前時間是否在生效時間Stime2~失效時間Etime2的時間範圍內，以及已用次數是否小於等於可用次數Times2。若當前時間在生效時間Stime2~失效時間Etime2的時間範圍內，且已用次數小於等於可用次數Times2，則第二普通應用程式116啟動成功。
這裏描述的各種技術可結合硬體或軟體，或者它們的組合一起實現。從而，本發明的方法和設備，或者本發明的方法和設備的某些方面或部分可採取嵌入有形媒體，例如可移動硬碟、USB隨身碟、軟碟、CD-ROM或者其它任意機器可讀的儲存媒體中的程式碼(即指令)的形式，其中當程式被載入諸如電腦之類的機器，並被所述機器執行時，所述機器變成實踐本發明的設備。
在程式碼在可程式化電腦上執行的情况下，計算設備一般包括處理器、處理器可讀的儲存媒體(包括易失性和非易失性記憶體和/或儲存元件)，至少一個輸入裝置，和至少一個輸出裝置。其中，記憶體被配置用於儲存程式碼；處理器被配置用於根據該記憶體中儲存的所述程式碼中的指令，執行本發明的基於可信執行環境的應用程式啟動方法。
以示例而非限制的方式，可讀媒體包括可讀儲存媒體和通信媒體。可讀儲存媒體儲存諸如電腦可讀指令、資料結構、程式模組或其它資料等資訊。通信媒體一般以諸如載波或其它傳輸機制等已調製資料信號來體現電腦可讀指令、資料結構、程式模組或其它資料，並且包括任何資訊傳遞媒體。以上的任一種的組合也包括在可讀媒體的範圍之內。
在此處所提供的說明書中，演算法和顯示不與任何特定電腦、虛擬系統或者其它設備固有相關。各種通用系統也可以與本發明的示例一起使用。根據上面的描述，構造這類系統所要求的結構是顯而易見的。此外，本發明也不針對任何特定程式化語言。應當明白，可以利用各種程式化語言實現在此描述的本發明的內容，並且上面對特定語言所做的描述是為了披露本發明的最佳實施方式。
在此處所提供的說明書中，說明了大量具體細節。然而，能夠理解，本發明的實施例可以在沒有這些具體細節的情况下被實踐。在一些實例中，並未詳細示出公知的方法、結構和技術，以便不模糊對本說明書的理解。
類似地，應當理解，為了精簡本公開並幫助理解各個發明方面中的一個或多個，在上面對本發明的示例性實施例的描述中，本發明的各個特徵有時被一起分組到單個實施例、圖、或者對其的描述中。然而，並不應將該公開的方法解釋成反映如下意圖：即所要求保護的本發明要求比在每個申請專利範圍中所明確記載的特徵更多特徵。更確切地說，如下面的申請專利範圍所反映的那樣，發明方面在於少於前面公開的單個實施例的所有特徵。因此，遵循具體實施方式的申請專利範圍由此明確地併入該具體實施方式，其中每個申請專利範圍本身都作為本發明的單獨實施例。
本領域那些技術人員應當理解在本文所公開的示例中的設備的模組或單元或組件可以布置在如該實施例中所描述的設備中，或者可替換地可以定位在與該示例中的設備不同的一個或多個設備中。前述示例中的模組可以組合為一個模組或者此外可以分成多個子模組。
本領域那些技術人員可以理解，可以對實施例中的設備中的模組進行自適應性地改變並且把它們設置在與該實施例不同的一個或多個設備中。可以把實施例中的模組或單元或組件組合成一個模組或單元或組件，以及此外可以把它們分成多個子模組或子單元或子組件。除了這樣的特徵和/或過程或者單元中的至少一些是相互排斥之外，可以採用任何組合對本說明書（包括伴隨的申請專利範圍、摘要和圖式）中公開的所有特徵以及如此公開的任何方法或者設備的所有過程或單元進行組合。除非另外明確陳述，本說明書（包括伴隨的申請專利範圍、摘要和圖式）中公開的每個特徵可以由提供相同、等同或相似目的的替代特徵來代替。
此外，本領域的技術人員能夠理解，儘管在此所述的一些實施例包括其它實施例中所包括的某些特徵而不是其它特徵，但是不同實施例的特徵的組合意味著處於本發明的範圍之內並且形成不同的實施例。例如，在下面的申請專利範圍中，所要求保護的實施例的任意之一都可以以任意的組合方式來使用。
此外，所述實施例中的一些在此被描述成可以由電腦系統的處理器或者由執行所述功能的其它裝置實施的方法或方法元素的組合。因此，具有用於實施所述方法或方法元素的必要指令的處理器形成用於實施該方法或方法元素的裝置。此外，裝置實施例的在此所述的元素是如下裝置的例子：該裝置用於實施由為了實施該發明的目的的元素所執行的功能。
如在此所使用的那樣，除非另行規定，使用序數詞“第一”、“第二”、“第三”等等來描述普通對象僅僅表示涉及類似對象的不同實例，並且並不意圖暗示這樣被描述的對象必須具有時間上、空間上、排序方面或者以任意其它方式的給定順序。
儘管根據有限數量的實施例描述了本發明，但是受益於上面的描述，本技術領域內的技術人員明白，在由此描述的本發明的範圍內，可以設想其它實施例。此外，應當注意，本說明書中使用的語言主要是為了可讀性和教導的目的而選擇的，而不是為了解釋或者限定本發明的主題而選擇的。因此，在不偏離申請專利範圍的範圍和精神的情况下，對於本技術領域的普通技術人員來說許多修改和變更都是顯而易見的。對於本發明的範圍，對本發明所做的公開是說明性的而非限制性的，本發明的範圍由申請專利範圍限定。Hereinafter, exemplary embodiments of the present disclosure will be described in more detail with reference to the drawings. Although the exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art. The invention provides an application program startup scheme based on a trusted execution environment. In the technical solution of the present invention, first, the trusted execution environment in the terminal device is activated. After the trusted execution environment has been activated, the trusted execution environment can provide trusted applications to other applications in the terminal device. Program activation and activation verification services to ensure the safety of other applications. Fig. 1 shows a schematic diagram of a startup system 100 of a trusted execution environment according to an embodiment of the present invention. As shown in FIG. 1, the system 100 includes a terminal device 110 and a server 120. It should be noted that although the system 100 shown in FIG. 1 only includes one terminal device 110 and one server 120, those skilled in the art will understand that in practice, the system 100 may include any number of terminal devices 110 and server 120. , The present invention does not limit the number of terminal devices 110 and server 120 included in the system 100. The terminal device 110 may be specifically implemented as any device, such as a mobile phone, a tablet computer, a smart wearable device, a smart home appliance, a car machine, a drone, etc., but is not limited to this. As shown in FIG. 1, a trusted execution environment (Trusted Execution Environment, TEE) and a rich execution environment (Rich Execution Environment, REE) are deployed in the terminal device 110. The trusted execution environment and the rich execution environment have mutually isolated hardware and independent operating systems to meet the operating requirements of applications with different security levels. The hardware isolation between the trusted execution environment and the rich execution environment can be achieved through, for example, the security extension technology of ARM TrustZone or C-SKY, but it is not limited to this. The operating system of the rich execution environment can be a general operating system such as Android, iOS, RTOS real-time operating system, and the operating system can run ordinary applications that do not require high security, such as instant messaging, camera, weather query, etc. The operating system of the trusted execution environment is usually a closed and relatively simple secure operating system. Trusted applications with high security requirements are run on the operating system, such as fingerprint recognition, identity authentication, electronic payment, and intelligence. Lock etc. Trusted applications in the trusted execution environment can be called by ordinary applications in the rich execution environment to achieve corresponding functions. Trusted applications cannot directly communicate with the outside (such as servers, other terminal devices, users, etc.), but need to use ordinary applications in a rich execution environment as a communication relay, that is, trusted applications in a trusted execution environment The program communicates with the outside through ordinary applications in the rich execution environment. The server 120 may be any device used to provide a trusted execution environment online startup service to the terminal device 110, such as a physical server, or a computing instance deployed in the physical server, but is not limited to this. The server 120 is used to provide the terminal device 110 with an online startup service of a trusted execution environment. After the trusted execution environment is activated, the terminal device 110 can use the trusted execution environment to process and protect sensitive data. In the embodiment of the present invention, the trusted execution environment includes a startup management application 112, and the startup management application 112 communicates with the server 120 via an interface application 113 deployed in the rich execution environment, and is used to perform the trusted execution environment start up. Specifically, the startup management application 112 reads the terminal device identification, and sends the terminal device identification to the server 120 via the interface application 113. The server 120 generates an activation code according to the terminal device identifier, generates a trusted identity identifier and a trusted key of the terminal device, and stores the trusted identity identifier and trusted key in association with the terminal device identifier. The trusted identity identifier is a character string that can represent the uniqueness of the device. It is used to uniquely identify the terminal device 110 and has the security attributes of being non-tamperable, non-forgeable, and globally unique. The trusted key is a character string derived through a specific algorithm based on the trusted identity, and is used to encrypt key information related to the terminal device 110. The server 120 encrypts the trusted identity, the trusted key, and the activation code to generate activation information, and sends the activation information to the activation management application 112 via the interface application 113. The startup management application 112 decrypts the startup information to obtain the trusted identity, the trusted key, and the startup code, and then encrypts and stores the trusted identity, the trusted key, and the startup code in the secure storage space 111. The secure storage space 111 is a designated space for storing files, and the files are stored in this location after being encrypted with a trusted key. In the embodiment of the present invention, the secure storage space 111 can and can only be accessed by the startup management application 112. After the trusted identity, the trusted key, and the activation code are encrypted and stored in the secure storage space 111, the trusted execution environment of the terminal device 110 is activated. Ordinary applications in the rich execution environment can call trusted applications in the trusted execution environment. When the trusted application is invoked, the invoked trusted application will further invoke the startup management application 112 to trigger the startup verification of the trusted execution environment. The startup management application 112 reads the trusted identity, trusted key, and startup code from the secure storage space 111, and verifies whether the trusted execution environment is successfully started based on the trusted identity, trusted key, and startup code, and then , The verification result is returned to the trusted application called by the ordinary application. If the verification start is successful, the called trusted application program executes the call of the ordinary application program, and returns the call result to the ordinary application program. For example, as shown in FIG. 1, the first ordinary application 114 in the rich execution environment is a shopping application, and the first trusted application 115 is an electronic payment application. When the user selects some commodities in the first common application 114 and needs to pay for the purchase, the first common application 114 calls the first trusted application 115 to implement the electronic payment function. After the first trusted application 115 is called, the startup management application 112 is triggered to perform the startup verification of the trusted execution environment. The startup management application 112 reads the trusted identity, trusted key, and startup code from the secure storage space 111, and verifies whether the trusted execution environment is successfully started based on the trusted identity, trusted key, and startup code, and The verification result is returned to the first trusted application. If the verification is successful, the first trusted application 115 executes the call of the first common application 114 to implement the electronic payment function, and returns the call result (whether the payment is successful) to the first common application 114. On the basis that the trusted execution environment has been activated, the trusted execution environment can provide application activation and activation verification services to other applications of the terminal device 110, thereby ensuring the security of other applications. FIG. 2 shows a schematic diagram of an application launching system 200 based on a trusted execution environment according to an embodiment of the present invention. As shown in FIG. 2, the system 200 includes a terminal device 110 and a server 120. A trusted execution environment and a rich execution environment are deployed in the terminal device 110, and a second common application 116 is deployed in the rich execution environment. After the trusted execution environment of the terminal device 110 has been activated, the second common application 116 can be activated based on the trusted execution environment. The server 120 further includes an application server 122 and an authentication server 124. The application server 122 is a server that provides methods and data calls to the second ordinary application 116, and can generate usage permission information for activating the second ordinary application 116 (such as effective time, expiration time, available times, etc.) . The authentication server 124 is used for verifying the identity of the terminal device 110, generating verification information based on the use permission information, and encrypting the use permission information and verification information, and so on. Specifically, the second common application 116 triggers the activation of the management application 112 to verify whether the trusted execution environment is successfully activated, and in the case that the trusted execution environment is successfully activated, the terminal device's trusted identity is sent to the application server. 122. The application server 122 sends the trusted identity identifier to the authentication server 124. The authentication server 124 verifies the identity of the terminal device 110 and returns the verification result to the application server 122. In the case where the authentication server 124 passes the verification, the application server 122 generates the usage permission information of the second common application 116 and sends the usage permission information to the authentication server 124. The authentication server 124 generates verification information according to the use authority information and the trusted identity identifier, combines the use authority information and the verification information into a registration code, obtains the trusted key corresponding to the trusted identity identifier, and uses the trusted key The registration code is encrypted to generate registration information, and the encrypted registration information is sent to the startup management application 112 via the application server 122 and the second ordinary application 116 in turn. The startup management application 112 obtains the trusted key from the secure storage space 111, uses the trusted key to decrypt the registration information to obtain the registration code, and encrypts and stores the registration code in the secure storage space 111. After the registration code is encrypted and stored in the secure storage space 111, the activation of the second common application 116 is completed. Fig. 3 shows a flowchart of a method 300 for starting a trusted execution environment according to an embodiment of the present invention. The method 300 is executed in a trusted execution environment of a terminal device (for example, the aforementioned terminal device 110), for example, executed by a startup management application 112 in the trusted execution environment. As shown in FIG. 3, the method 300 starts at step S310. In step S310, the terminal device identifier is sent to the server. The terminal device identifier is used to uniquely identify a terminal device. Since the terminal device identification is unique, it can also be called a device fingerprint. The terminal device identification can be, for example, the MAC (Media Access Control) address of the terminal device, CPU serial number, hard disk serial number and other information, or the calculation result obtained by processing the terminal device's MAC address, CPU serial number and other information Etc., but not limited to this. The present invention does not limit the specific content of the terminal equipment identification. According to an embodiment, the terminal device identification is obtained by calling a corresponding data interface, which is usually provided by the manufacturer of the terminal device. Specifically, step S310 is executed by the startup management application in the trusted execution environment. The startup management application 112 cannot directly communicate with the server, but sends the terminal device identification to the server via the interface application 113 in the rich execution environment. According to an embodiment, in addition to sending the terminal device identification to the server, an authentication code can also be generated based on the terminal device identification, and the authentication code is sent to the server together, so that the server can verify the authentication code. After the verification is passed, the activation code is generated according to the terminal device identification. According to an embodiment, the authentication code includes a preset key, a first cipher text, and a first mapping value, where the first cipher text is a cipher text generated by using the preset key to encrypt the session key and the terminal device identifier , The first mapping value is a value obtained by using a preset mapping function to map the session key and the terminal device identifier. According to one embodiment, the preset key is one of the configuration information of the startup management application 112, and accordingly, the value of the preset key can be read from the configuration information of the startup management application. The session key is generated by the terminal device, for example, by the startup management application 112. According to one embodiment, when the startup management application 112 communicates with the server, the startup management application 112 will generate a token for this communication. The token includes the preset password read from the configuration information. Key and the generated session key. According to the preset key and the session key in the token, the first ciphertext can be determined, and then the authentication code can be generated. Those skilled in the art can understand that in addition to the preset key and the session key, the token may also include other information, such as the application ID of the startup management application 112, the version number of the startup management application 112, and the preset For key usage, preset key type, etc., the present invention does not limit the specific information included in the token. In addition, it should be noted that the encryption algorithm used to generate the first ciphertext and the mapping function used to generate the first mapping value can be set by those skilled in the art, and the present invention does not limit this. For example, the encryption algorithm used to generate the first ciphertext may be an AES encryption algorithm, and the mapping function used to generate the first mapping value may be a hash algorithm, but is not limited to this. After the authentication code is generated, the authentication code and the terminal device identification are sent to the server together, so that the server can verify the authentication code, recover the session key from it, and ensure that the authentication code and terminal device identification are not affected during transmission. Intercepted or maliciously tampered with. According to an embodiment, the server can verify the authentication code according to the following method: read the preset key from the authentication code, and use the preset key to decrypt the first cipher text in the authentication code to obtain the session Key and terminal device identification. Subsequently, the preset mapping function is used to calculate the second mapping value of the session key and the terminal device identifier. If the second mapping value is consistent with the first mapping value in the authentication code, the authentication code verification is passed. Those skilled in the art can understand that in order to enable the server to verify the authentication code, certain algorithm parameters need to be disclosed between the terminal device and the server, such as the encryption algorithm used to generate the first ciphertext, and the first The mapping function used for the mapping value, etc. These parameters can be agreed upon in advance by the terminal device and the server before the terminal device transmits the terminal device identification and authentication code to the server; these parameters can also be used as the fields of the authentication code and transmitted to the server together with the authentication code; etc. . The invention does not limit the specific method for synchronizing the algorithm parameters between the terminal equipment and the server. Table 1 shows an example of the authentication code AuthCode1 during the startup process of the trusted execution environment: Table 1 Preset key First ciphertext First mapping value
Provisioning Key1 Provisioning_Key_Encrypt(Session Key+Dev_FP) Hash_Sha256(Session Key+Dev_FP)
In Table 1, the preset key is Provisioning Key1, and the first cipher text is Provisioning_Key_Encrypt (Session Key + Dev_FP), that is, the first cipher text is the use of provisioning key Provisioning Key1 to identify the session key Session Key and the terminal device. Encrypted ciphertext obtained by Dev_FP. The first mapping value is Hash_Sha256 (Session Key+Dev_FP), that is, the first mapping value is the hash value of the session key Session Key and the terminal device identifier Dev_FP calculated using the SHA256 algorithm. Those skilled in the art can understand that, in practice, in addition to the fields listed in Table 1, the authentication code AuthCode1 may also include other fields, such as the application identifier of the startup management application 112, and the version of the startup management application 112. Number, preset key usage, preset key type, etc. The present invention does not limit the number and types of fields included in the authentication code. After sending the authentication code AuthCode1 and the terminal device identifier Dev_FP shown in Table 1 to the server, the server will verify the authentication code: first, read the provisioning key Provisioning Key1 from the authentication code AuthCode1. Subsequently, the Provisioning Key1 is used to decrypt the first ciphertext Provisioning_Key_Encrypt (Session Key + Dev_FP) to recover the Session Key. Finally, the SHA256 algorithm is used to calculate the hash value of the recovered session key Session Key and the terminal device identifier Dev_FP. If the hash value is consistent with the first mapping value in AuthCode1, the authentication of AuthCode1 is successful. Subsequently, in step S320, the activation information returned by the server is received. The activation information includes the encrypted trusted identity identifier, the trusted key, and the activation code. The trusted identity identifier, the trusted key, and the terminal device identifier correspond to each other. Correspondingly, the activation code is generated according to the terminal device identification. The trusted identity and the trusted key are generated by the server. The server generates a trusted identity identifier and a trusted key, and stores the trusted identity identifier and the trusted key in association with the terminal device identifier. A trusted identity identifier is a string that can represent the uniqueness of a device, and is used to uniquely identify a terminal device, and it has the security attributes of being non-tamperable, non-forgeable, and globally unique. The trusted key is a character string derived through a specific algorithm based on the trusted identity, and is used to encrypt key information related to the terminal device corresponding to the trusted identity. The startup code is generated according to the terminal device identification, and is used to start the trusted execution environment of the terminal device. According to an embodiment, the activation code includes usage authority information and verification information of the trusted execution environment. The use authority information of the trusted execution environment is used to mark the use authority of the trusted execution environment. The usage authority information may include, for example, effective time, expiration time, and available times, but is not limited to this. When the use authority information includes effective time and expiration time, the terminal device can only use the trusted execution environment normally within the effective time ~ expiration time range, and the terminal device's credibility is outside the effective time ~ expiration time range. The execution environment is not started, and the trusted execution environment is not available. When the usage authority information includes the available times, the terminal device can only call the trusted execution environment within the available times. If the terminal device calls the trusted execution environment for the available times, the trusted execution environment will be in an unstarted state. The letter execution environment is unavailable. Those skilled in the art can understand that the usage authority information can be configured, which can include at least one of effective time, expiration time, and available times, and can also include other information other than effective time, expiration time, and available times. The invention does not restrict the specific content included in the use permission information. The verification information is used to verify the activation code to ensure that the activation code has not been illegally tampered with. According to an embodiment, the verification information includes a cipher text generated by encrypting the trusted identity identifier, usage authority information, and terminal device identifier using a trusted key. The present invention does not limit the specific encryption algorithm used to generate the verification information. For example, the encryption algorithm used to generate the verification information may be, for example, the HMAC (Hash-based Message Authentication Code) algorithm, but is not limited thereto. Table 2 shows an example of the activation code ActiCode: Table 2 Permission information Calibration information
Effective time Expiration time Available times
Stime1 Etime1 Times1 HMAC(IDkey, Dev_FP + ID+Stime1+ Etime1+Times1)
In Table 2, the usage authority information includes effective time Stime1, expiration time Etime1, and available times Times1. The verification information is HMAC (IDkey, Dev_FP + ID + Stime1 + Etime1 + Times1), that is, the verification information is based on the HMAC algorithm, using the trusted key IDkey to identify the terminal device Dev_FP, the trusted identity ID, and the effective time Stime1, expiration time Etime1, and available times Times1 are encrypted message digests. Those skilled in the art can understand that, in practice, in addition to the fields listed in Table 2, the activation code ActiCode can also include other fields, such as the algorithm used to encrypt the activation code ActiCode with a trusted key IDkey , The key check value KCV (Key Checksum Value) used to verify whether the trusted key IDkey has been tampered with, and the algorithm for generating the key check value KCV, etc., the present invention has There are no restrictions on the number and types of bits. In step S320, the activation information includes the encrypted trusted identity, the trusted key, and the activation code. According to an embodiment, the activation information can be generated according to the following steps: using a trusted key to encrypt the activation code to generate the activation code ciphertext; using a session key to identify the trusted identity, the trusted key, and the activation code ciphertext Encryption to generate activation information. The session key is determined in advance by the terminal device and the server. For example, the session key can be agreed upon in advance by the terminal device and the server before the terminal device transmits the terminal device identification and authentication code to the server; for example, see Table 1. Session Key Session Key can be implicit in the authentication code AuthCode1 and passed to the server; etc. The present invention does not limit the generation of the session key and the transfer method of the session key between the terminal device and the server. In addition, the encryption algorithm used to generate the activation code ciphertext and the activation information can be any encryption algorithm, which is not limited by the present invention. Taking Table 1 and Table 2 as examples, the steps for generating the activation information are as follows: First, the activation code ActiCode is encrypted with the trusted key IDkey to generate activation code ciphertext ActiCode'. Subsequently, the Session Key determined from the authentication code AuthCode1 is used to encrypt the trusted identity ID, the trusted key IDkey, and the activation code ciphertext ActiCode' to generate activation information. After the activation information is received in step S320, step S330 is executed. In step S330, the activation information is decrypted to obtain a trusted identity, a trusted key, and an activation code. The process of decrypting the activation information is opposite to the process of encrypting the activation information on the server side. According to an embodiment, the activation information is decrypted according to the following steps: first, the activation information is decrypted using the session key to obtain the trusted identity, the trusted key, and the ciphertext of the activation code; then, the trusted key is used Decrypt the cipher text of the activation code to obtain the activation code. Taking Table 2 as an example, the decryption process of the activation information is as follows: First, the session key Session Key is used to decrypt the activation information to obtain the trusted identity ID, the trusted key IDkey, and the activation code ciphertext ActiCode'. Subsequently, the trusted key IDkey is used to decrypt the activation code ciphertext ActiCode' to obtain the activation code ActiCode. After obtaining the trusted identity identifier, the trusted key and the activation code in step S330, step S340 is executed. In step 340, the trusted identity, the trusted key, and the activation code are encrypted and stored in a secure storage space. The data in the secure storage space can only be read by the startup management application 112 in the trusted execution environment, which ensures that the data in it will not be illegally obtained and tampered with. According to an embodiment, after the trusted identity, trusted key, and activation code are obtained in step S330, the trusted identity, trusted key, and activation code are not directly encrypted and stored in the secure storage space, but first The activation code is verified according to the terminal device identification to ensure that the activation information has not been illegally tampered with during the transmission process between the server and the terminal device. After the activation code is verified, the trusted identity, the trusted key and the activation code are encrypted and stored in a secure storage space. According to an embodiment, the activation code can be verified according to the following steps: using a trusted key to encrypt the trusted identity identification, usage authority information, and terminal device identification to generate a second cipher text; if the second cipher text is in the activation code If the verification information is the same, the activation code verification is passed. Taking Table 2 as an example, the verification process of the activation code ActiCode is as follows: Obtain the terminal device identifier Dev_FP (for example, through the data interface provided by the terminal device manufacturer). Based on the HMAC algorithm, a trusted key IDkey is used to encrypt the terminal device identification Dev_FP, the trusted identity identification ID, the effective time Stime1, the expiration time Etime1, and the available times Times1 to generate the second ciphertext. If the second cipher text is consistent with the verification information in the activation code, the activation code verification is passed. Otherwise, the verification fails. After the trusted identity, the trusted key, and the activation code are encrypted and stored in the secure storage space 111, the trusted execution environment of the terminal device is activated. The trusted identity, trusted key, and activation code in the secure storage space 111 can only be read by the activation management application 112 in the trusted execution environment. Fig. 4 shows a schematic diagram of a startup process of a trusted execution environment according to an embodiment of the present invention. In FIG. 4, the secure storage space 111, the startup management application 112, and the interface application 113 are all located in the terminal device 110. The startup management application 112 is a trusted application in a trusted execution environment, and the interface application 113 is a rich execution Ordinary applications in the environment. In step S401, the user triggers the activation management application 112 to perform the activation verification of the trusted execution environment through the interface application 113. In steps S402 and S403, the activation management application 112 reads the activation code ActiCode of the trusted execution environment from the secure storage space 111, verifies the ActiCode, and sends the verification result to the interface application 113 in step S404. If no ActiCode is stored in the secure storage space 111 or the activation management application 112 fails to verify the ActiCode, then in step S404, the activation management application 112 will return to the interface application 113 a result that the trusted execution environment has not been activated. Subsequently, step S405 is executed. In step S405, the interface application 113 triggers the activation of the management application 112 to activate the trusted execution environment. In step S406, the startup management application 112 obtains the terminal device identifier Dev_FP through the interface provided by the terminal device manufacturer, obtains the provisioning key Provisioning Key1, and generates the session key Session Key. In step S407, the management application 112 is started to generate the authentication code AuthCode1 according to the terminal device identifier Dev_FP. As shown in Table 1, AuthCode1 includes the provisioning key Provisioning Key1, the first ciphertext Provisioning_Key_Encrypt (Session Key + Dev_FP), and The first mapping value Hash_Sha256 (Session Key + Dev_FP). In step S408, the management application 112 is activated to send the terminal device identifier Dev_FP and the authentication code AuthCode1 to the interface application 113. In step S409, the interface application 113 sends the terminal device identifier Dev_FP and the authentication code AuthCode1 to the server 120. In step S410, the server 120 verifies the authentication code AuthCode1: first, read the provisioning key Provisioning Key1 from the authentication code AuthCode1. Subsequently, the Provisioning Key1 is used to decrypt the first ciphertext Provisioning_Key_Encrypt (Session Key + Dev_FP) to recover the Session Key. Finally, the SHA256 algorithm is used to calculate the hash value of the recovered session key Session Key and the terminal device identifier Dev_FP. If the hash value is consistent with the first mapping value in AuthCode1, the authentication of AuthCode1 is successful. Subsequently, step S411 is executed. In step S411, the server 120 generates a trusted identity ID and a trusted key IDkey, and stores the trusted identity ID and the trusted key IDkey in association with the terminal device identifier Dev_FP. In step S412, the server 120 generates the activation code ActiCode according to the terminal device identifier Dev_FP. As shown in Table 2, the ActiCode includes the effective time Stime1, the expiration time Etime1, the available times Times1, and the verification information HMAC (IDkey, Dev_FP + ID + Stime1 + Etime1 +Times1). Use the trusted key IDkey to encrypt the activation code ActiCode to generate the activation code ciphertext ActiCode'; use the session key Session Key to encrypt the trusted identity ID, the trusted key IDkey, and the activation code ciphertext ActiCode', Generate activation information. In step S413, the server 120 sends the activation information to the interface application 113. In step S414, the interface application 113 sends the activation information to the activation management application 112. In step S415, the startup management application 112 uses the Session Key to decrypt the startup information to obtain the trusted identity ID, the trusted key IDkey, and the activation code ciphertext ActiCode'. Subsequently, the trusted key IDkey is used to decrypt the activation code ciphertext ActiCode' to obtain the activation code ActiCode. In step S416, the startup management application 112 obtains the terminal device identifier Dev_FP through the data interface provided by the manufacturer of the terminal device. Based on the HMAC algorithm, a trusted key IDkey is used to encrypt the terminal device identification Dev_FP, the trusted identity identification ID, the effective time Stime1, the expiration time Etime1, and the available times Times1 to generate the second ciphertext. If the second cipher text is consistent with the verification information in the activation code, the activation code verification is passed, and step S417 is executed. In steps S417 and S418, the startup management application 112 encrypts and stores the trusted identity ID, the trusted key IDkey, and the activation code ActiCode in the secure storage space 111, and the trusted execution environment is successfully activated. In step S419, the startup management application 112 feeds back the successful result of the trusted execution environment startup to the interface application 113. FIG. 5 shows a flowchart of a method 500 for starting a trusted execution environment according to an embodiment of the present invention. The method 500 is executed in a server (for example, the server 120 shown in FIG. 1), which corresponds to the aforementioned method 300 executed in a terminal device. As shown in FIG. 5, the method 500 starts at step S510. In step S510, the terminal device identifier sent by the terminal device is received. Since the startup management application 112 cannot directly communicate with the server, it needs to communicate with the server through the interface application 113 in the rich execution environment. Therefore, in step S510, the server receives the terminal from the interface application 113 Equipment Identity. According to an embodiment, in step S510, in addition to receiving the terminal device identifier, an authentication code sent by the terminal device is also received, and the authentication code is generated according to the terminal device identifier. The authentication code is verified, and after the authentication code is verified, step S520 is executed to generate an activation code according to the terminal device identification. According to an embodiment, the authentication code includes a preset key, a first cipher text, and a first mapping value, where the first cipher text is a cipher text generated by using the preset key to encrypt the session key and the terminal device identifier , The first mapping value is a value obtained by using a preset mapping function to map the session key and the terminal device identifier. Correspondingly, the server can verify the authentication code according to the following method: read the preset key from the authentication code, and use the preset key to decrypt the first cipher text in the authentication code to obtain the session key And terminal device identification. Subsequently, the preset mapping function is used to calculate the second mapping value of the session key and the terminal device identifier. If the second mapping value is consistent with the first mapping value in the authentication code, the authentication code verification is passed. For the specific implementation steps of the generation and verification of the authentication code, reference may be made to the relevant description of the aforementioned step S310, which will not be repeated here. Subsequently, in step S520, a trusted identity identifier and a trusted key corresponding to the terminal device identifier are generated, and an activation code is generated according to the terminal device identifier. The trusted identity identifier is used to uniquely identify a terminal device, and it has security attributes that cannot be tampered with, cannot be forged, and are globally unique. The trusted key is a key corresponding to the trusted identity, which is used to encrypt key information. The server can generate the trusted identity identifier and the trusted key according to any algorithm, and the present invention does not limit the specific algorithm used to generate the trusted identity identifier and the trusted key. After the trusted identity and the trusted key are generated, the trusted identity and the trusted key are associated and stored. The startup code is generated according to the terminal device identification, and is used to start the trusted execution environment of the terminal device. According to an embodiment, the activation code includes usage authority information and verification information of the trusted execution environment. The use authority information of the trusted execution environment is used to mark the use authority of the trusted execution environment. The usage authority information may include, for example, effective time, expiration time, and available times, but is not limited to this. The verification information is used to verify the activation code to ensure that the activation code has not been illegally tampered with. According to an embodiment, the verification information includes a cipher text generated by encrypting the trusted identity identifier, usage authority information, and terminal device identifier using a trusted key. The present invention does not limit the specific encryption algorithm used to generate the verification information. For example, the encryption algorithm used to generate the verification information may be, for example, the HMAC algorithm, but is not limited thereto. An example of the activation code ActiCode can refer to the aforementioned Table 2, which will not be repeated here. Subsequently, in step S530, the trusted identity, the trusted key and the activation code are encrypted to generate activation information. According to one embodiment, the activation code is encrypted with a trusted key to generate the activation code cipher text; the session key is used to encrypt the trusted identity, the trusted key, and the activation code cipher text to generate the activation information. For the specific steps of generating the activation information, reference may be made to the related description of step S320, which will not be repeated here. Subsequently, in step S540, the activation information is sent to the terminal device, so that the terminal device: decrypts the activation information to obtain the trusted identity identifier, the trusted key and the activation code, and the trusted identity identifier, the trusted key And the activation code is encrypted and stored in a secure storage space. For the specific implementation process of step S540, reference may be made to the related descriptions of the foregoing steps S330 and 340, which are not repeated here. Ordinary applications in the rich execution environment can call trusted applications in the trusted execution environment. When the trusted application is invoked, the invoked trusted application will further invoke the startup management application 112 to trigger the startup verification of the trusted execution environment. FIG. 6 shows a flowchart of a method 600 for verifying the startup of a trusted execution environment according to an embodiment of the present invention. The method 600 is executed in the trusted execution environment of the terminal device, for example, executed by the startup management application 112 in the trusted execution environment. As shown in FIG. 6, the method 600 starts at step S610. In step S610, the trusted identity, the trusted key, and the activation code of the trusted execution environment are obtained. The activation code includes the use authority information and verification information of the trusted execution environment, and the verification information includes the use of a trusted key pair. The cipher text generated by encrypting the trusted identity identification, usage authority information, and terminal equipment identification. According to one embodiment, the startup management application 112 reads the trusted identity ID, the trusted key IDkey, and the startup code ActiCode of the trusted execution environment from the secure storage space 111. The activation code ActiCode further includes usage rights information. For example, as shown in Table 2, the activation code ActiCode includes three usage rights information: effective time Stime1, expiration time Etime1, and available times Times1, as well as verification information HMAC (IDkey, Dev_FP + ID + Stime1 + Etime1 +Times1). The verification information is based on the HMAC algorithm, using the trusted key IDkey to encrypt the terminal device ID Dev_FP, the trusted identity ID, the effective time Stime1, the expiration time Etime1, and the available times Times1. Subsequently, in step S620, the terminal device identifier is obtained, and the trusted identity identifier, usage authority information, and terminal device identifier are encrypted using a trusted key to generate a third ciphertext. According to one embodiment, the terminal device identifier Dev_FP is obtained through the data interface provided by the terminal device manufacturer, and based on the HMAC algorithm, the trusted key IDkey is used to identify the trusted identity ID, effective time Stime1, expiration time Etime1, and available times Times1 and the terminal device identifier Dev_FP are encrypted to generate the third ciphertext. Subsequently, in step S630, if the third ciphertext is consistent with the verification information, and the current use environment of the terminal device matches the use authority information, the trusted execution environment is successfully activated. For example, the usage authority information includes effective time, expiration time, and available times. Accordingly, the current use environment of the terminal device includes information such as time and used times. If the current time of the terminal device is within the range of effective time to expiration time, and the number of times used is less than or equal to the number of available times, the current use environment of the terminal device matches the use authority information. Fig. 7 shows a schematic diagram of a startup verification process of a trusted execution environment according to an embodiment of the present invention. In FIG. 7, the secure storage space 111, the startup management application 112, the first trusted application 115, and the first ordinary application 114 are all located in the terminal device 110, and the startup management application 112 and the first trusted application 115 are The trusted application program in the trusted execution environment, the first ordinary application program 114 is the ordinary application program in the rich execution environment. In step S701, the first normal application 114 initiates a call request to the first trusted application 115. In step S702, the first trusted application 115 triggers the startup management application 112 to perform the startup verification of the trusted execution environment. In steps S703 and S704, the startup management application 112 reads the trusted identity ID, the trusted key IDkey, and the startup code ActiCode of the trusted execution environment from the secure storage space 111. As shown in Table 2, ActiCode includes effective time Stime1, expiration time Etime1, available times Times1, and verification information HMAC (IDkey, Dev_FP + ID + Stime1 + Etime1 + Times1). In step S705, the startup management application 112 obtains the terminal device identifier Dev_FP through the data interface provided by the manufacturer of the terminal device. Based on the HMAC algorithm, the trusted key IDkey is used to encrypt the trusted identity ID, the effective time Stime1, the expiration time Etime1, the available times Times1, and the terminal device ID Dev_FP to generate the third ciphertext. If the third cipher text is consistent with the verification information in the activation code, the activation code verification is passed and the trusted execution environment has been activated. In step S706, the activation management application 112 sends the result that the trusted execution environment has been activated to the first trusted application 115. In step S707, the first trusted application 115 executes the call requested by the first normal application 114. In step S708, the first trusted application 115 returns the invocation result to the first normal application 114. On the basis that the trusted execution environment has been activated, the trusted execution environment can provide application activation and activation verification services to other applications of the terminal device 110, thereby ensuring the security of other applications. FIG. 8 shows a flowchart of a method 800 for starting an application program based on a trusted execution environment according to an embodiment of the present invention. The method 800 is executed in the trusted execution environment of the terminal device, for example, executed by the startup management application 112 in the trusted execution environment. The method 200 can be used to start a common application program in a rich execution environment, such as the second common application program 116 shown in FIG. 2. As shown in FIG. 8, the method 800 starts at step S810. In step S810, the trusted identity of the terminal device is sent to the server. The trusted identity identifier is stored in the secure storage space 111 of the terminal device, and it can only be read by a specific trusted application in the trusted execution environment, such as the startup management application 112. After the startup management application 112 obtains the trusted identity, it sends the trusted identity to the server 120 through the application to be started in the rich execution environment (for example, the second ordinary application 116 in FIG. 2 ). According to one embodiment, before sending the trusted identity to the server, it is necessary to verify whether the trusted execution environment is started successfully; in the case that the trusted execution environment is started successfully, then the trusted identity of the terminal device is sent to Server. Specifically, the steps shown in the aforementioned method 600 can be followed to verify whether the trusted execution environment is successfully started. If the trusted execution environment is successfully started, the trusted execution environment is available, and the application to be started can be started based on the trusted execution environment. If the trusted execution environment fails to start, the trusted execution environment is unavailable. At this time, the aforementioned method 300 needs to be executed to start the trusted execution environment, and the method 800 of the present invention can be executed after the trusted execution environment is started. According to an embodiment, in addition to sending the trusted identity to the server, step S810 also generates an authentication code based on the trusted identity, and sends the authentication code and the trusted identity to the server so that the server can authenticate Code is verified. After the authentication code is verified, the registration code is generated according to the trusted identity. According to an embodiment, the authentication code includes a preset key, a fourth cipher text, and a third mapping value, where the fourth cipher text is a cipher text generated by using the preset key to encrypt the trusted identity, and the third The mapping value is a value obtained by mapping the trusted identity identifier using a preset mapping function. According to one embodiment, the preset key is one of the configuration information of the startup management application 112, and accordingly, the value of the preset key can be read from the configuration information of the startup management application. According to one embodiment, when the startup management application 112 communicates with the server, the startup management application 112 will generate a token for this communication. The token includes the preset password read from the configuration information. key. According to the preset key in the token, the fourth ciphertext can be determined, and then the authentication code can be generated. Those skilled in the art can understand that in addition to the preset key and the session key, the token may also include other information, such as the application ID of the startup management application 112, the version number of the startup management application 112, and the preset For key usage, preset key type, etc., the present invention does not limit the specific information included in the token. In addition, it should be noted that the encryption algorithm used to generate the fourth ciphertext and the mapping function used to generate the third mapping value can be set by those skilled in the art, and the present invention does not limit this. For example, the encryption algorithm used to generate the fourth ciphertext may be an AES encryption algorithm, and the mapping function used to generate the third mapping value may be a hash algorithm, but is not limited to this. After the authentication code is generated, the authentication code and the trusted identity are sent to the server so that the server can verify the authentication code to ensure that the authentication code and the trusted identity are not tampered with during transmission. According to an embodiment, the server can verify the authentication code according to the following method: read the preset key from the authentication code, use the preset key to decrypt the fourth ciphertext to obtain the trusted identity identification, and use the preset key Set the mapping function to calculate the fourth mapping value of the trusted identity identifier. If the fourth mapping value is consistent with the third mapping value in the authentication code, the authentication code verification is passed. Table 3 shows an example of the authentication code AuthCode2 in the application startup process based on the trusted execution environment: Table 3 Preset key Fourth ciphertext Third mapping value
Provisioning Key2 Provisioning_Key_Encrypt(ID) Hash_Sha256(ID)
In Table 3, the preset key is Provisioning Key2, and the fourth cipher text is Provisioning_Key_Encrypt(ID), that is, the fourth cipher text is the cipher text obtained by using the preset key Provisioning Key2 to encrypt the trusted identity ID. . The third mapping value is Hash_Sha256(ID), that is, the third mapping value is the hash value of the trusted identity identification ID calculated using the SHA256 algorithm. Those skilled in the art can understand that, in practice, in addition to the fields listed in Table 3, the authentication code AuthCode2 may also include other fields, such as the application identifier of the startup management application 112, and the version of the startup management application 112. Number, preset key usage, preset key type, etc. The present invention does not limit the number and types of fields included in the authentication code. After sending the authentication code AuthCode2 shown in Table 3 to the server, the server will verify the authentication code: First, read the provisioning key Provisioning Key2 from the authentication code AuthCode2. Subsequently, the fourth ciphertext Provisioning_Key_Encrypt (ID) is decrypted by using Provisioning Key2 to obtain a trusted identity identification ID. Finally, the SHA256 algorithm is used to calculate the hash value of the trusted identity ID. If the hash value is consistent with the third mapping value in AuthCode2, the AuthCode2 verification is successful. Subsequently, in step S820, the registration information returned by the server is received, the registration information includes a registration code encrypted with a trusted key corresponding to the trusted identity, and the registration code is generated based on the trusted identity. The registration code is generated based on the trusted identity and used to activate the application to be activated. According to an embodiment, the registration code includes usage authority information and verification information of the application to be activated. The usage permission information of the application is used to mark the usage permission of the application. The usage authority information may include, for example, effective time, expiration time, and available times, but is not limited to this. When the usage authority information includes effective time and expiration time, the user can only use the application normally within the effective time ~ expiration time range, and the application is not available outside the effective time ~ expiration time time range. When the usage permission information includes the available times, the user can only use the application within the available times. If the user uses the application for the available times, the application is no longer available. Those skilled in the art can understand that the usage authority information can be configured, which can include at least one of effective time, expiration time, and available times, and can also include other information other than effective time, expiration time, and available times. The invention does not restrict the specific content included in the usage authority information of the application. The verification information is used to verify the registration code to ensure that the registration code has not been illegally tampered with. According to one embodiment, the verification information includes a cipher text generated by encrypting the trusted identity and usage authority information using a trusted key. The present invention does not limit the specific encryption algorithm used to generate the verification information. For example, the encryption algorithm used to generate the verification information may be, for example, the HMAC (Hash-based Message Authentication Code) algorithm, but is not limited thereto. Table 4 shows an example of the registration code License: Table 4 Permission information Calibration information
Effective time Expiration time Available times
Stime2 Etime2 Times2 HMAC(IDkey, ID + Stime2 + Etime2 +Times2)
In Table 4, the usage authority information of the application includes the effective time Stime2, the expiration time Etime2, and the available times Times2. The verification information is HMAC (IDkey, ID + Stime2 + Etime2 + Times2), that is, the verification information is based on the HMAC algorithm, using a trusted key IDkey to identify the trusted identity ID, effective time Stime2, expiration time Etime2 and available The message digest generated by Times2 encryption. In step S820, the registration information includes the registration code encrypted by the trusted key corresponding to the trusted identity. That is, the server first determines the trusted key corresponding to the trusted identity, and then uses the trusted key to encrypt the registration code to generate registration information. It should be noted that the process of encrypting the registration code to generate registration information in method 800 is slightly different from the process of encrypting the activation code to generate activation information in method 300. In the method 300, the activation code is double-encrypted by the trusted key and the session key; in the method 800, the registration code is only single-encrypted by the trusted key. This is because, in the method 300, the trusted key is generated for the first time, and the trusted key needs to be sent to the terminal device along with the activation code. In order to ensure that the trusted key is not intercepted or tampered with, after using the trusted key to encrypt the startup code, it is also necessary to use the session key to encrypt the trusted key, so that the trusted key is invisible to the outside. In method 800, the trusted key is not transmitted, but is only stored in the terminal device and the server, even if other devices monitor the registration information transmitted between the terminal device and the server, because the trusted key cannot be obtained, It is also unable to decrypt the registration information to obtain the registration code. Therefore, in the method 800, the security of the registration code can be ensured by only using the trusted key to perform single-encryption of the registration code, and there is no need to use the session key for secondary encryption. Subsequently, in step S830, the trusted key is used to decrypt the registration information to obtain the registration code. Subsequently, in step S840, the registration code is encrypted and stored in a secure storage space. The data in the secure storage space can only be read by the startup management application 112 in the trusted execution environment, which ensures that the data in it will not be illegally obtained and tampered with. According to one embodiment, after the registration code is obtained in step S830, the registration code is not directly encrypted and stored in a secure storage space, but the registration code is first verified according to the trusted identity to ensure that the registration information is stored on the server and the terminal device. No illegal tampering during transmission. After the registration code is verified, the registration code is encrypted and stored in a secure storage space. According to an embodiment, the registration code can be verified according to the following steps: use a trusted key to encrypt the trusted identity and usage authority information to generate a fifth cipher text; if the fifth cipher text and the verification information in the registration code If they are consistent, the registration code verification is passed. Taking Table 4 as an example, the verification process of the registration code license is as follows: Obtain the trusted key IDkey, based on the HMAC algorithm, use the trusted key IDkey to identify the trusted identity ID, effective time Stime2, expiration time Etime2, and available times Times2 Encryption is performed to generate the fifth ciphertext. If the fifth cipher text is consistent with the verification information in the registration code, the registration code verification is passed. Otherwise, the verification fails. After the registration code of the application to be activated is encrypted and stored in the secure storage space 111, the activation of the application to be activated is completed. The registration code in the secure storage space 111 can only be read by the startup management application 112 in the trusted execution environment. Fig. 9 shows a schematic diagram of an application startup process based on a trusted execution environment according to an embodiment of the present invention. In FIG. 9, the secure storage space 111, the startup management application 112, and the second common application 116 are located in the terminal device. The startup management application 112 is a trusted application in a trusted execution environment, and the second common application 116 is The application to be launched in a rich execution environment. The application server 122 and the authentication server 124 are located on the server. The application server 122 is used to provide methods and data calls to the second common application 116 to generate usage authority information (for example, effective time, expiration time, available times, etc.) of the second common application 116. The authentication server 124 is used to verify the identity of the terminal device 110 and encrypt related data. In step S901, the second ordinary application 116 initiates a request to initialize the trusted execution environment to the startup management application 112. The startup management application 112 performs startup verification on the trusted execution environment based on the request. If the trusted execution environment startup verification is successful, step S902 is executed. In steps S902 and S903, the startup management application 112 reads the trusted identity ID and the trusted key IDkey from the secure storage space 111. In step S904, the startup management application 112 generates the authentication code AuthCode2 according to the trusted identity ID. As shown in Table 3, AuthCode2 includes the preset key Provisioning Key2, the fourth cipher text Provisioning_Key_Encrypt(ID), and the third mapping. The value Hash_Sha256(ID). In step S905, the startup management application 112 sends the trusted identity ID and the authentication code AuthCode2 to the second common application 116. In step S906, the second ordinary application 116 sends the trusted identity ID and the authentication code AuthCode2 to the application server 122. In step S907, the application server 122 sends the trusted identity ID and the authentication code AuthCode2 to the authentication server 124. In step S908, the authentication server 124 verifies the authentication code AuthCode2: first, read the provisioning key Provisioning Key2 from the authentication code AuthCode2. Subsequently, the fourth ciphertext Provisioning_Key_Encrypt (ID) is decrypted by using Provisioning Key2 to obtain a trusted identity identification ID. Finally, the SHA256 algorithm is used to calculate the hash value of the trusted identity ID. If the hash value is consistent with the third mapping value in AuthCode2, the AuthCode2 verification is successful. In step S909, the authentication server 124 returns the result of successful verification of the authentication code AuthCode2 to the application server 122. In step S910, the application server 122 generates the usage authority information of the second common application 116, referring to Table 4, the usage authority information includes the effective time Stime2, the expiration time Etime2, and the available times Times2. In step S911, the application server 122 sends the generated usage authority information to the authentication server 124. In step S912, the authentication server 124 generates verification information. Referring to Table 4, the verification information is HMAC (IDkey, ID + Stime2 + Etime2 + Times2). Subsequently, the use authority information and verification information are combined to form a registration code License. Find the trusted key IDkey corresponding to the trusted identity ID, and use the IDkey to encrypt the license to generate registration information. In steps S913 to S915, the authentication server 124 sequentially passes through the application server 122 and the second ordinary application 116, and sends the registration information to the startup management application 112. In step S916, the startup management application 112 uses the trusted key IDkey to decrypt the registration information to obtain the registration code License. Use the trusted key IDkey to encrypt the trusted identity ID, the effective time Stime2, the expiration time Etime2, and the available times Times2 to generate the fifth ciphertext. If the fifth ciphertext is consistent with the verification information in the license, the registration code verification is passed, and step S917 is executed. In steps S917 and S918, the startup management application 112 encrypts and stores the registration code License in the secure storage space 111, and the second common application 116 is successfully activated. In step S919, the startup management application 112 feeds back the result of the successful startup of the second common application 116 to the second common application 116. FIG. 10 shows a flowchart of a method 1000 for launching an application program based on a trusted execution environment according to an embodiment of the present invention. The method 100 is executed on the server (for example, the server 120 shown in FIG. 2), which corresponds to the aforementioned method 800 executed in the terminal device, and is suitable for the application to be started (for example, the second ordinary application shown in FIG. 2). Program 116) to start. According to an embodiment, the server further includes an application server (for example, the application server 122 shown in FIG. 2) and an authentication server (for example, the authentication server 124 shown in FIG. 2), the application server and the authentication service End-to-end division of labor and collaboration to achieve application startup based on a trusted execution environment. The application server can directly communicate with the application to be started, and is used to provide methods and data calls to the application to be started, and generate the usage permission information of the application to be started (such as effective time, expiration time, available times, etc.) . The authentication server usually does not directly communicate with the application to be started, and is used to verify the identity of the terminal device 110 and encrypt related data. As shown in FIG. 10, the method 1000 starts at step S1010. In step S1010, the trusted identity sent by the terminal device is received. The trusted identity identifier is stored in the secure storage space 111 of the terminal device, and it can only be read by a specific trusted application in the trusted execution environment, such as the startup management application 112. After the activation management application 112 obtains the credible identity identifier, it is sent to the application server through the application to be activated. Correspondingly, the application server receives the trusted identity identifier sent by the application to be started. According to an embodiment, in step S1010, in addition to receiving the trusted identity identifier, the authentication code sent by the terminal device is also accepted, and the authentication code is generated based on the trusted identity identifier. The authentication code is verified. After the authentication code is verified, step S520 is executed to generate the registration code according to the trusted identity. According to one embodiment, after the application server 122 receives the trusted identity identifier and the authentication code sent by the second ordinary application 116, the application server 122 forwards the trusted identity identifier and the authentication code to the authentication server 124, and the authentication server 124 to verify the authentication code. For the specific verification process of the authentication code, reference may be made to the related description of the foregoing step S810, which will not be repeated here. Subsequently, in step S1020, a registration code is generated according to the trusted identity. According to one embodiment, the registration code includes usage permission information and verification information of the application to be activated, wherein the usage permission information is used to mark the usage permission of the application, which may include, for example, effective time, expiration time, and available times, etc. , But not limited to this. The verification information is used to verify the registration code to ensure that the registration code has not been illegally tampered with. According to one embodiment, the verification information includes a cipher text generated by encrypting the trusted identity and usage authority information using a trusted key. According to one embodiment, the usage permission information in the registration code is generated by the application server 122. After the application server 122 generates the usage permission information, it sends the usage permission information to the authentication server 124, and the authentication server 124 generates verification information. For the specific generation process of the usage authority information and the verification information, please refer to the related description of the aforementioned step S820, which will not be repeated here. Subsequently, in step S1030, the trusted key corresponding to the trusted identity is used to encrypt the registration code to generate registration information. According to an embodiment, step S1030 is performed by the authentication server 124. Subsequently, in step S1040, the registration information is sent to the terminal device so that the terminal device: decrypts the registration information with a trusted key to obtain the registration code; and encrypts the registration code and stores it in a secure storage space. In step S1040, the authentication server 124 sequentially passes through the application terminal 122 and the application to be activated, and sends the registration information to the activation management application 112 in the terminal device. The startup management application 112 uses the trusted key to decrypt the registration information to obtain the registration code; and encrypts and stores the registration code in a secure storage space. For the specific implementation process of step S1040, reference may be made to the related descriptions of the foregoing steps S830 and S840, which will not be repeated here. When a user uses an application, the activation verification of the application will be triggered. The user can use the application only when it is verified that the application is launched successfully; if the application fails to be verified, the application is not available to the user. FIG. 11 shows a flowchart of a method 1100 for verifying application startup based on a trusted execution environment according to an embodiment of the present invention. The method 1100 is executed in the trusted execution environment of the terminal device, for example, executed by the startup management application 112 in the trusted execution environment. As shown in FIG. 11, the method 1100 starts at step S1110. In step S1110, obtain a trusted identity identifier, a trusted key, and a registration code of the application to be verified. The registration code includes usage authority information and verification information. The verification information is the use of the trusted key to identify the trusted identity , Use permission information to encrypt the ciphertext generated. According to one embodiment, the startup verification application 112 obtains the trusted identity, the trusted key, and the registration code of the application to be verified from the secure storage space 111. Subsequently, in step S1120, a trusted key is used to encrypt the trusted identity and usage authority information to generate a sixth ciphertext. Subsequently, in step S1130, if the sixth cipher text is consistent with the verification information, the registration code is sent to the application to be verified, so that the application can determine whether it is successfully activated according to whether the current use environment matches the use permission information . For example, the usage authority information includes effective time, expiration time, and available times. Accordingly, the current use environment of the application includes information such as time, used times, and so on. If the current time is within the range of effective time to expiration time, and the number of used times of the application is less than or equal to the number of available times, the current use environment matches the use permission information, and the application is launched successfully. Fig. 12 shows a schematic diagram of an application startup verification process based on a trusted execution environment according to an embodiment of the present invention. In FIG. 12, the secure storage space 111, the startup management application 112, and the second common application 116 are all located in the terminal device 110. The startup management application 112 is a trusted application in a trusted execution environment, and the second common application is 116 is a common application in a rich execution environment. In step S1201, when the user uses the second common application 116, the second common application 116 initiates an activation verification request to the activation management application 112. In steps S1202 and S1203, the startup management application 112 obtains the trusted identity ID, the trusted key IDkey, and the startup code ActiCode of the trusted execution environment from the secure storage space 111. In step S1204, the startup management application 112 verifies whether the trusted execution environment is successfully started according to the trusted identity ID, the trusted key IDkey, and the activation code ActiCode. In the case that the trusted execution environment is successfully started, step S1205 is continued to be executed. In steps S1205 and S1206, the startup management application 112 obtains the registration code License from the secure storage space 111. Refer to Table 4, the license includes the effective time Stime2, the expiration time Etime2, the available times Times2, and the verification information HMAC (IDkey, ID + Stime2 + Etime2 + Times2). In step S1207, the startup management application 112 uses the trusted key IDkey to encrypt the trusted identity ID, the effective time Stime2, the expiration time Etime2, and the available times Times2 to generate a sixth ciphertext. If the sixth ciphertext is consistent with the verification information in the license, step S1208 is executed. In step S1208, the management application 112 is activated to send the registration code to the second common application 116. In step S1209, the second common application 116 obtains the current use environment, and the current use environment includes the current time and the number of times the second common application 116 has been used. Read the effective time Stime2, the expiration time Etime2, and the available times Times2 in the registration code. Determine whether the current time is within the time range from the effective time Stime2 to the expiration time Etime2, and whether the used times are less than or equal to the available times Times2. If the current time is within the time range from the effective time Stime2 to the expiration time Etime2, and the used times are less than or equal to the available times Times2, the second ordinary application 116 is successfully activated. The various technologies described here can be implemented in combination with hardware or software, or a combination of them. Therefore, the method and device of the present invention, or some aspects or parts of the method and device of the present invention may be embedded in a tangible medium, such as a removable hard disk, a USB flash drive, a floppy disk, a CD-ROM, or any other machine readable The form of program code (ie, instructions) in the storage medium of which when the program is loaded into a machine such as a computer and executed by the machine, the machine becomes a device for practicing the present invention. When the program code is executed on a programmable computer, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), and at least one input Device, and at least one output device. The memory is configured to store program codes; the processor is configured to execute the application startup method based on the trusted execution environment of the present invention according to instructions in the program codes stored in the memory. By way of example and not limitation, readable media include readable storage media and communication media. The readable storage medium stores information such as computer readable instructions, data structures, program modules, or other data. Communication media generally use modulated data signals such as carrier waves or other transmission mechanisms to embody computer-readable instructions, data structures, program modules, or other data, and include any information delivery media. Combinations of any of the above are also included in the scope of readable media. In the instructions provided here, the algorithms and displays are not inherently related to any particular computer, virtual system or other equipment. Various general-purpose systems can also be used with the examples of the present invention. From the above description, the structure required to construct this type of system is obvious. In addition, the present invention is not directed to any specific programming language. It should be understood that various programming languages can be used to implement the content of the present invention described herein, and the above description of specific languages is for the purpose of disclosing the best embodiments of the present invention. In the instructions provided here, a lot of specific details are explained. However, it can be understood that the embodiments of the present invention can be practiced without these specific details. In some instances, well-known methods, structures, and technologies are not shown in detail, so as not to obscure the understanding of this specification. Similarly, it should be understood that in order to simplify the present disclosure and help understand one or more of the various inventive aspects, in the above description of the exemplary embodiments of the present invention, the various features of the present invention are sometimes grouped together into a single embodiment. , Figure, or its description. However, the disclosed method should not be interpreted as reflecting the intention that the claimed invention requires more features than those clearly recorded in the scope of each patent application. More precisely, as reflected in the scope of the patent application below, the invention lies in less than all the features of the single embodiment disclosed above. Therefore, the scope of patent applications following the specific embodiments is thus clearly incorporated into the specific embodiments, wherein each patent scope itself serves as a separate embodiment of the present invention. Those skilled in the art should understand that the modules or units or components of the device in the example disclosed herein can be arranged in the device as described in this embodiment, or alternatively can be positioned with the device in the example In one or more different devices. The modules in the foregoing examples can be combined into one module or can be divided into multiple sub-modules. Those skilled in the art can understand that it is possible to adaptively change the modules in the device in the embodiment and set them in one or more devices different from the embodiment. The modules or units or components in the embodiments can be combined into one module or unit or component, and in addition, they can be divided into multiple sub-modules or sub-units or sub-components. Except that at least some of such features and/or processes or units are mutually exclusive, any combination can be used to compare all features disclosed in this specification (including the accompanying patent scope, abstract and drawings) and any method disclosed in this manner. Or all the processes or units of the equipment are combined. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying patent scope, abstract and drawings) can be replaced by an alternative feature providing the same, equivalent or similar purpose. In addition, those skilled in the art can understand that although some embodiments described herein include certain features included in other embodiments but not other features, the combination of features of different embodiments means that they are within the scope of the present invention. Within and form different embodiments. For example, in the scope of the following patent applications, any one of the claimed embodiments can be used in any combination. In addition, some of the described embodiments are described herein as methods or combinations of method elements that can be implemented by a processor of a computer system or by other devices that perform the described functions. Therefore, a processor with the necessary instructions for implementing the method or method element forms a device for implementing the method or method element. In addition, the elements described herein of the device embodiments are examples of devices for implementing functions performed by the elements for the purpose of implementing the invention. As used herein, unless otherwise specified, the use of ordinal numbers "first", "second", "third", etc. to describe ordinary objects merely refers to different instances of similar objects, and is not intended to imply such The described objects must have a given order in terms of time, space, order, or in any other way. Although the present invention has been described in terms of a limited number of embodiments, benefiting from the above description, those skilled in the art understand that other embodiments can be envisaged within the scope of the invention thus described. In addition, it should be noted that the language used in this specification is mainly selected for readability and teaching purposes, not for explaining or limiting the subject of the present invention. Therefore, without departing from the scope and spirit of the scope of the patent application, many modifications and changes are obvious to those of ordinary skill in the art. As for the scope of the present invention, the disclosure of the present invention is illustrative rather than restrictive, and the scope of the present invention is defined by the scope of the patent application.
