本公開通常涉及計算機系統(tǒng)，并且特別涉及這樣的系統(tǒng)中的軟件代碼的完整性。
背景技術(shù)：
：：本節(jié)旨在向讀者介紹技術(shù)的各個方面，這可能與下面描述和/或要求保護的本公開的各個方面有關(guān)。認為該討論有助于向讀者提供背景信息以便于更好地理解本公開的各個方面。因此，應(yīng)當理解，要從該角度來閱讀這些陳述，而不是作為對現(xiàn)有技術(shù)的承認。由于各種原因，通常希望確保處理設(shè)備執(zhí)行未被篡改的軟件。為此目的，可以使用不同的技術(shù)來保護軟件鏡像免受篡改攻擊。最常用的技術(shù)是在代碼片段上計算簽名或校驗和，然后在稍后的階段驗證簽名或校驗和。通常在沒有任何秘密的情況下計算和驗證校驗和，而生成加密簽名需要私鑰和對應(yīng)公鑰驗證簽名?；谛ｒ灪偷谋Ｗo的示例是windows操作系統(tǒng)中使用的可移植可執(zhí)行(pe)格式的crc32。pe頭包含crc32字段，其給出對應(yīng)代碼段的校驗和。為了成功繞過保護，攻擊者首先修改代碼段，然后利用在經(jīng)修改的代碼段上計算的新值來替代原始校驗和。這種類型的攻擊是可能的，因為攻擊者不需要任何秘密來更新經(jīng)修改的代碼段的校驗和。鑒于校驗和的弱點，加密簽名是優(yōu)選解決方案。簽名的生成在代碼釋放之前被執(zhí)行并且使用私有(因此是秘密)密鑰。相關(guān)聯(lián)的公鑰被附加到代碼，并且稍后用于在代碼安裝或運行時校驗代碼完整性。攻擊者仍然可以修改代碼，但是由于在沒有私鑰的情況下無法生成代碼的正確簽名，所以攻擊失敗。存在用于校驗以本機代碼傳遞和執(zhí)行的應(yīng)用的完整性的許多解決方案，諸如由arxan(guardittm)、metaforic(metafortresstm)等提供的解決方案。本機代碼是可由處理器直接執(zhí)行的匯編器指令的集合。安裝之后指令集合不改變，這意味著程序完整性值在安裝之前和安裝之后保持相同(即隨時間保持不變)。在這種情況下，簽名可以被預(yù)先生成并且與應(yīng)用包一起傳遞。另一方面，以解釋代碼(諸如以java編寫的代碼、安卓dex代碼等)的形式分發(fā)的應(yīng)用包括在其被執(zhí)行之前必須通過解釋器的中間指令。與本機代碼不同，解釋代碼可以在安裝時間之后被修改以用于優(yōu)化目的。代碼修改通常非常依賴于目標平臺，因此不一定是可預(yù)測的。如果代碼被修改，則根據(jù)解釋代碼所生成的簽名不能用于在運行時動態(tài)地校驗代碼完整性和真實性。為了將應(yīng)用軟件分發(fā)和安裝到前面提到的安卓操作系統(tǒng)上，使用稱為apk(androidapplicationpackage，安卓應(yīng)用包)的文件格式。為了制作apk文件，首先將針對安卓的程序編譯為中間語言，然后將它的部分打包成壓縮存檔文件(zip格式)。存檔文件包含單個dex(dalvikexecutablecode，dalvik可執(zhí)行代碼)文件中的整個程序代碼、各種資源(例如鏡像文件)以及apk文件的清單。存檔文件包括兩個附加文件：cert.sf和cert.rsa。cert.sf包含所有其他存檔文件的加密散列；cert.rsa包含用于簽名驗證的公鑰。只有cert.sf利用rsa私鑰被簽名。cert.sf的rsa簽名使得能夠在安裝期間驗證apk文件的整個內(nèi)容。實際上，cert.sf文件中提到的所有文件都是間接簽名的，因為cert.sf包含它們的散列。在安裝之前更改任何文件將導(dǎo)致錯誤，因為軟件將檢測到文件摘要與cert.sf文件中的散列不匹配。替選地，修改cert.sf文件內(nèi)的加密散列值(如在已經(jīng)描述的對基于校驗和的驗證的攻擊中)將在簽名驗證期間導(dǎo)致錯誤。dex文件頭還包含dex文件內(nèi)容的全局校驗和。在首次執(zhí)行應(yīng)用時，安卓系統(tǒng)使用優(yōu)化器，在執(zhí)行之前該優(yōu)化器及時將dex解釋字節(jié)代碼修改為稱為odex(優(yōu)化dex)的優(yōu)化機器指令序列。優(yōu)化器還更新校驗和。然后將odex文件存儲在安卓文件系統(tǒng)中的特定存儲庫中以用于將來使用。然后odex文件成為應(yīng)用軟件的參考，并且當其存在時，不再使用原始dex文件。在運行時，系統(tǒng)可以使用odex校驗和來驗證應(yīng)用的完整性。然而，在安卓操作系統(tǒng)和用于執(zhí)行odex代碼的dalvik機器中，該選項不是默認設(shè)置的，并不總是校驗odex校驗和，因為校驗和驗證對執(zhí)行性能具有不可忽視的影響。安卓版本5.0及更高版本引入了替代dalvik機器的安卓運行時間(androidruntime，art)。應(yīng)用仍然以dex代碼部署，但是在安裝時，使用提前編譯(aot)功能將dex代碼編譯為本機代碼。對dex文件的aot編譯產(chǎn)生二進制可執(zhí)行可鏈接格式(elf)文件。然后將應(yīng)用的dex代碼編譯一次，并且然后每次執(zhí)行應(yīng)用時隨后啟動elf代碼。當art直接運行本機代碼(elf代碼)時，帶來更快的應(yīng)用執(zhí)行并改善總體功耗。因此可以看出，在安卓系統(tǒng)中，只在安裝時驗證apk簽名。此外，如果用戶允許安裝來自不可信的源的應(yīng)用，則apk即使在未被由中央機構(gòu)簽名時，也可以安裝在安卓設(shè)備上。然后應(yīng)用開發(fā)者使用他們擁有的自簽名證書，其不與任何可信機構(gòu)鏈接。在這種情況下，經(jīng)篡改的應(yīng)用可以由其所有者不知道的安卓設(shè)備上的任何黑客退出并重新安裝。如已經(jīng)提到的，安卓應(yīng)用使用解釋器可移植格式(dex)。該可移植格式可以在具有不同架構(gòu)和特性的大量設(shè)備上執(zhí)行：arm、x86、mips、小/大字節(jié)序(little/bigendian)等。為了提高性能，dex代碼在安裝時或者在首次使用應(yīng)用時被修改，以產(chǎn)生odex或者針對目標設(shè)備優(yōu)化的elf二進制。在優(yōu)化或oat編譯期間，可能在代碼中修改各種內(nèi)容：指令可能被其他指令替代，指令的對齊可能被改變，字節(jié)順序可能被交換，等等。于是優(yōu)化和oat編譯引發(fā)安全問題。雖然仍然可以使用cert.sf和cert.rsa來驗證dex文件的簽名，但是對于odex和elf文件而言不是這樣的情況，因為odex和elf文件已被修改，并且它們的完整性不再與原始dex簽名鏈接。換句話說，完整性和真實性只能在安裝時被驗證，而不能在運行時被驗證，因為攻擊者能夠修改odex和elf代碼，并相應(yīng)地更新頭部中的最終校驗和。因此，系統(tǒng)容易受到至少兩類攻擊：遠程攻擊和根源攻擊。在遠程攻擊中，下載的惡意應(yīng)用提升其權(quán)限并獲得系統(tǒng)許可。然后惡意應(yīng)用可以篡改存儲在內(nèi)部儲存器的緩存存儲庫上的odex和elf文件。在根源攻擊中，攻擊者獲得安卓設(shè)備，例如通過竊取設(shè)備或者通過在所有者不存在時訪問設(shè)備，無需鎖定設(shè)備會話。攻擊者可以通過usb鏈接從設(shè)備的內(nèi)部儲存器取回所安裝的應(yīng)用，修改應(yīng)用，然后將經(jīng)修改的應(yīng)用推回到內(nèi)部儲存器上。為了使后者的攻擊成功，設(shè)備必須是“根源的”(即需要“根源訪問”來控制設(shè)備的安卓系統(tǒng))。因此，安卓應(yīng)用完整性的信任可能在應(yīng)用的生命周期期間被破壞?？梢孕湃伟沧肯到y(tǒng)上安裝的內(nèi)容，但不一定是正在運行的內(nèi)容。應(yīng)當理解，期望具有解決方案，其克服與解釋代碼應(yīng)用的完整性和真實性相關(guān)的問題的至少一部分。本公開提供這樣的解決方案。技術(shù)實現(xiàn)要素：在第一方面，本公開針對一種用于處理應(yīng)用的設(shè)備。該設(shè)備包括接口，被配置為接收應(yīng)用，存儲器，被配置為存儲應(yīng)用和經(jīng)修改的應(yīng)用的簽名的校驗和，以及處理單元，被配置為修改應(yīng)用以獲得經(jīng)修改的應(yīng)用，生成經(jīng)修改的應(yīng)用的校驗和，使用簽名密鑰對經(jīng)修改的應(yīng)用的校驗和進行簽名，以及將簽名的校驗和存儲在存儲器中。第一方面的各種實施例包括：·應(yīng)用包括第一校驗和，并且處理單元還被配置為使用第一校驗和來驗證應(yīng)用的完整性。有利的是，對第一校驗和進行簽名，并且處理單元還被配置為驗證第一校驗和的簽名?！ぬ幚韱卧€配置為在執(zhí)行經(jīng)修改的應(yīng)用期間使用簽名的校驗和來驗證經(jīng)修改的應(yīng)用的完整性?！?yīng)用實現(xiàn)為解釋代碼，并且將經(jīng)修改的應(yīng)用實現(xiàn)為優(yōu)化解釋代碼，或者將經(jīng)修改的應(yīng)用編譯為本機代碼?！ぴO(shè)備是智能手機或平板?！な褂密浖Ｗo技術(shù)來保護簽名密鑰?！ぬ幚韱卧慌渲脼樯山?jīng)修改的代碼的多個校驗和，每個校驗和是針對經(jīng)修改的代碼的不同部分而生成的，并且對經(jīng)修改的代碼的多個校驗和進行簽名?！ぬ幚韱卧慌渲脼獒槍?jīng)修改的代碼的多個校驗和生成單個簽名?！ご鎯ζ鬟€被配置為存儲經(jīng)修改的應(yīng)用和簽名密鑰的證書，并且處理器還被配置為將簽名密鑰的證書存儲在存儲器中。在第二方面，本公開針對一種用于處理應(yīng)用的方法。設(shè)備接收應(yīng)用，修改應(yīng)用以獲得經(jīng)修改的應(yīng)用，生成經(jīng)修改的應(yīng)用的校驗和，使用簽名密鑰對經(jīng)修改的應(yīng)用的校驗和進行簽名，以及將簽名的校驗和存儲在存儲器中的存儲器中。第二方面的各種實施例包括：·應(yīng)用包括第一校驗和，并且該方法還包括使用第一校驗和來驗證應(yīng)用的完整性?！Φ谝恍ｒ灪瓦M行簽名，并且該方法還包括驗證第一校驗和的簽名。·該方法還包括在執(zhí)行經(jīng)修改的應(yīng)用期間使用簽名的校驗和來驗證經(jīng)修改的應(yīng)用的完整性?！ぴ摲椒ㄟ€包括將經(jīng)修改的應(yīng)用和簽名密鑰的證書存儲在存儲器中。附圖說明現(xiàn)在將參照附圖通過非限制性示例來描述本公開的優(yōu)選特征，附圖中：圖1圖示了實現(xiàn)本公開的示例性系統(tǒng)；圖2圖示了示例性系統(tǒng)功能方面；圖3圖示了根據(jù)本公開的優(yōu)選實施例的方法的優(yōu)選實施例。具體實施方式圖1圖示了實現(xiàn)本公開的示例性系統(tǒng)。系統(tǒng)包括設(shè)備110和應(yīng)用提供商(應(yīng)用商店)120。設(shè)備110可以是運行安卓os的任何種類的合適的設(shè)備，諸如智能電話或平板，并且它包括至少一個硬件處理單元(“處理器”)111、存儲器112、用于與用戶交互的用戶接口113、以及用于通過諸如因特網(wǎng)的連接140與應(yīng)用提供商120通信的通信接口114。本領(lǐng)域技術(shù)人員將理解，為清楚起見，所示設(shè)備是非常簡化的，并且另外的實際設(shè)備將包括諸如電源和永久儲存器的特征。應(yīng)用提供商120存儲可以由設(shè)備110下載的至少一個應(yīng)用apk文件122，該apk文件包括由簽名實體簽名的apk證書。圖2圖示了示例性系統(tǒng)的功能方面。設(shè)備110的os210包括簽名模塊212和嵌入的可信實體214。可信實體214存儲簽名密鑰215與對應(yīng)的簽名證書216。簽名密鑰215可以是(至少在統(tǒng)計上)對于設(shè)備或者對于os的版本唯一的，并且其可以被對于每個設(shè)備唯一的設(shè)備密鑰保護。證書由簽名實體直接簽名或者通過信任鏈簽名。應(yīng)用220包括由簽名實體簽名的apk證書222、應(yīng)用代碼224(安裝之前的dex和安裝之后的odex或elf)、用于存儲odex或elf校驗和的保留空間226、用于存儲odex或elf簽名以及簽名證書的保留空間228、以及包括完整性驗證模塊232的庫230。簽名模塊212被配置為驗證應(yīng)用的apk證書222，計算應(yīng)用的odex或elf校驗和，以及在安裝應(yīng)用時對odex或elf校驗和進行簽名。簽名模塊212可以在dalvik虛擬機中或者在優(yōu)化或oat編譯dex的單元中實現(xiàn)。任何適當?shù)默F(xiàn)有技術(shù)驗證技術(shù)驗證apk證書222。簽名模塊212被配置為將odex或elf校驗和以及簽名插入應(yīng)用的緩存存儲庫中的保留空間226、228中。簽名模塊212還將簽名證書216存儲在緩存存儲庫中。應(yīng)當理解，可以使用多個校驗和，例如針對整個dex代碼的一個校驗和以及針對dex代碼的一部分的至少一個另外的校驗和。在這種情況下，簽名模塊212驗證所有校驗和，生成對應(yīng)的odex或elf校驗和，對所有生成的odex或elf校驗和進行簽名(有利地使用單個簽名)，并且將odex或elf校驗和以及簽名存儲在緩存存儲庫中。完整性驗證模塊232包括在apk的本機庫中，并且訪問擴展的jni庫，其允許在執(zhí)行期間的任何時間校驗odex或elf校驗和以及對應(yīng)簽名。完整性驗證模塊232被配置為當作為應(yīng)用的一部分被執(zhí)行時，以任何合適的方式校驗簽名證書，校驗odex或elf校驗和的簽名，計算odex或elf的當前校驗和，并且將計算出的校驗和與經(jīng)簽名(和驗證)的校驗和進行比較。應(yīng)當理解，如果任何校驗失敗，則可以采取合適的措施。圖3圖示了根據(jù)優(yōu)選實施例的方法的流程圖。在步驟s302中，設(shè)備110接收應(yīng)用的apk文件，并且在步驟s304中驗證apk證書。在安裝應(yīng)用期間，在步驟s306中設(shè)備110優(yōu)化或oat編譯apk文件中的dex，并且獲得緩存存儲庫中的odex或elf。在步驟s308中，設(shè)備110計算odex的至少一個odex或elf校驗和，并且在步驟s310中使用簽名密鑰215對odex或elf校驗和進行簽名。在步驟s312中，設(shè)備110將odex或elf校驗和以及簽名證書存儲在應(yīng)用的緩存存儲庫中的保留空間226、228中。然后設(shè)備110可以在步驟s314中在任何合適的時間執(zhí)行odex或elf，并且在執(zhí)行期間，完整性驗證模塊232可以通過計算與保留空間226中的經(jīng)簽名的odex或elf校驗和進行比較的當前odex或elf校驗和來在步驟s316中校驗odex或elf的完整性。在執(zhí)行應(yīng)用期間可以多次校驗完整性。要注意的是，該解決方案需要對當前部署的安卓系統(tǒng)進行輕微修改。在本描述中，術(shù)語“校驗和”旨在覆蓋實現(xiàn)在生成校驗和之后驗證所生成的數(shù)據(jù)是否被修改的值。因此校驗和可以例如也是散列值、循環(huán)冗余校驗(crc)值或其他種類的摘要；優(yōu)選的是，從校驗和獲得代碼是計算上不可行的。此外，雖然為了清楚起見使用了單個校驗和，但是可以使用多個校驗和，其中可以針對代碼的不同部分(其中不同部分可以重疊)生成校驗和，并且針對代碼的不同部分的多個校驗和用于生成單個的全局校驗和，其用于比較。簽名可以是任何合適的加密簽名，諸如基于散列的消息認證碼(hmac)或者基于例如rsa、數(shù)字簽名算法(dsa)或橢圓曲線數(shù)字簽名算法(ecdsa)的簽名。應(yīng)當理解，本解決方案可以成功地抵抗根源攻擊和遠程攻擊二者。盡管已在安卓環(huán)境中描述了本解決方案，但是它可以適用于在安裝期間修改代碼而不實現(xiàn)在運行時對安裝的應(yīng)用進行安全的完整性驗證的其他操作系統(tǒng)。因此，應(yīng)當理解，本公開提供了可以在安卓設(shè)備上實現(xiàn)應(yīng)用的運行時完整性的解決方案。本描述中公開的每個特征和(在適當?shù)那闆r下)權(quán)利要求和附圖可以獨立地或以任何適當?shù)慕M合提供。描述為以硬件實現(xiàn)的特征也可以以軟件實現(xiàn)，反之亦然。權(quán)利要求中出現(xiàn)的參考標號僅作為說明，并且對權(quán)利要求的范圍沒有限制性影響。當前第1頁12當前第1頁12