WO2017166561A1 - 一种基于安卓***apk下载方法及其*** - Google Patents
一种基于安卓***apk下载方法及其*** Download PDFInfo
- Publication number
- WO2017166561A1 WO2017166561A1 PCT/CN2016/093437 CN2016093437W WO2017166561A1 WO 2017166561 A1 WO2017166561 A1 WO 2017166561A1 CN 2016093437 W CN2016093437 W CN 2016093437W WO 2017166561 A1 WO2017166561 A1 WO 2017166561A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- apk
- public key
- verification
- key certificate
- application list
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Definitions
- the invention relates to the field of signature authentication, in particular to an Android system APK download method and a system thereof.
- Android Android is an open source operating system based on Linux architecture developed by Google. The installer on it is in APK (Android Package) format.
- the acquiring terminal In the field of financial payment, the acquiring terminal (such as the banking system) generally purchases the intelligent terminal equipment (POS machine) of the payment terminal manufacturer (such as each POS machine manufacturer), and the collection terminal performs centralized management of the payment terminal, including parameter downloading.
- the acquiring system installs its own program on the payment terminal and maintains the signed APK for the payment terminal device. It may also need to install the APK to other Android devices.
- the terminal In order to ensure the legitimacy of the program on the payment terminal, the terminal needs to introduce a digital signature scheme.
- the root public key certificate issued by the terminal to the acquirer is only signed by the private key corresponding to the work public key certificate of the root public key certificate.
- the APK can be installed to the payment terminal. If the information such as the version of the APK needs to be updated and upgraded, the newly upgraded APK needs to be re-signed by the acquirer before being downloaded and installed to the payment terminal. In this way, even if the APK has been credited, the update and upgrade still need to be re-signed and verified.
- the process of repeating the signature verification increases the workload of the terminal, and prolongs the time taken for the APK update and upgrade, and delays the payment terminal. normal work.
- the Chinese Patent Publication No. CN101425114 discloses a software upgrade package encapsulation method, and specifically discloses the following steps: a.
- the software upgrade package issuer determines a plurality of certification organizations that need to verify the upgrade package; b.
- the information summary obtained by the software plaintext after hashing is encrypted by the private keys of multiple certification bodies to obtain the digital signature of each certification authority; c.
- the software upgrade package publisher will clear the software, the digital signature of each certification body and each The digital certificate of the certification body is reassembled and sent to the terminal device as a software upgrade package.
- the above update installation still needs to be verified by the certification authority's signature. It still cannot eliminate the impact of the terminal re-signing and verification on the normal operation of the terminal every time the APK is upgraded.
- the technical problem to be solved by the present invention is to provide an Android system APK download method and a system thereof, and simplify the verification process of the download process under the premise of ensuring the security of the APK, and facilitate the update and upgrade of the credit card.
- the technical solution adopted by the present invention is:
- a download method based on the Android system APK including:
- the terminal After the terminal acquires the signature APK, the validity of the APK after the signature is verified, and after the verification is passed, the credit application list file is stored;
- the terminal verifies the legality of the APK
- An Android-based APK download system that includes:
- a first signature module configured to sign an APK including a credit application list file, and obtain a signed APK, where the credit application list file includes a package name of each credit APK and a corresponding public key certificate;
- a first acquiring module configured to acquire, by the terminal, the APK after the signature
- a first verification module configured to verify validity of the APK after the signature
- a storage module configured to: when the verification result of the first verification module is verified, storing the credit application list file;
- a second verification module configured to acquire an APK, and the terminal verifies the legality of the APK
- a first determining module when the verification result of the second verification module is not passed, determining whether the header of the one APK and the corresponding public key certificate are stored in the credit application list file;
- the third verification module is configured to verify the validity of the one APK by using an Android signature mechanism when the determination result of the first determination module is YES.
- the invention has the beneficial effects that the APK downloading method and the system thereof of the present invention allow the trusted APK to be downloaded to the terminal without being signed by the private key corresponding to the working public key certificate of the terminal root public key certificate. Because it is a credited APK, it ensures that the source of the APK is reliable and meets the security requirements. At the same time, since the security of the APK has been confirmed, there is no need to go through the signing of the acquiring institution, and the terminal is based on the acquiring institution.
- the verification process of the root public key certificate, the secure and reliable credit APK can be directly downloaded and installed to the terminal, which greatly simplifies the update and upgrade process of the credit APK; avoids the update and upgrade of the credit APK, affecting the normal operation of the terminal, and reducing the acquiring system and the terminal.
- the work load can also ensure the legitimacy of the installed APK.
- FIG. 1 is a schematic flow chart of a method for downloading an Android system based on the method of the present invention
- FIG. 2 is a schematic diagram of an APK downloading process including a credit application list in an Android system APK download method according to the present invention
- FIG. 3 is a schematic diagram of an APK verification process in an Android system APK download method according to the present invention.
- FIG. 4 is a schematic diagram of a functional module of an Android system APK download system according to the present invention.
- FIG. 5 is a schematic diagram of a composition of a first signature module in an Android system APK download system according to the present invention
- FIG. 6 is a schematic diagram of a composition of a first verification module in an Android system APK download system according to the present invention
- FIG. 7 is a schematic diagram of the composition of a third verification module in an Android system APK download system according to the present invention.
- the first signature module 2. the first acquisition module; 3. the first verification module;
- a third generating unit 32, a first verifying unit; 33, a second verifying unit;
- the most critical idea of the present invention is to download the APK containing the credit application list file to the terminal according to the existing signature verification mechanism; and determine whether the APK and the signature certificate that cannot pass the acceptance mechanism of the acquiring institution are stored in the credit application list. To determine whether the APK is credited, only the credited APK will continue the system's native check.
- the present invention provides a method for downloading an APK based on an Android system, including:
- the terminal After the terminal acquires the signature APK, the validity of the APK after the signature is verified, and after the verification is passed, the credit application list file is stored;
- the terminal verifies the legality of the APK
- the beneficial effect of the present invention is that the terminal presets the public key certificate of the acquiring institution, and only the APK or the existing signature of the private key corresponding to the working public key certificate of the acquiring institution root public key certificate is used.
- the APK in the credit application list can be downloaded to the terminal, ensuring that the illegal APK cannot be downloaded to the terminal payment device, ensuring the security of the downloaded APK.
- the credited APK can be signed by the private key corresponding to the work public key certificate of the terminal root public key certificate, and can be downloaded to the terminal through the terminal verification by using the trusted work public key certificate and the private key signature.
- the payment device is convenient for updating and upgrading the credit card, and the process of signing the verification by the acquiring institution after each update and upgrade is eliminated.
- the “signing the APK containing the credit application list file and obtaining the signed APK” is specifically:
- the acquiring institution generates a public key certificate for the work of the acquiring institution, and delivers the public key corresponding to the working public key certificate of the acquiring institution to different manufacturers;
- the acquiring institution signs the APK containing the credit application list file by using the private key corresponding to the acquiring public key certificate of the acquiring institution to generate signature data;
- a post-signal APK containing the acquirer work public key certificate and the signature data is generated.
- the “authentication of the APK after the signature is verified, after the verification is passed, storing the credit application list file” is specifically:
- the terminal uses the acquirer root certificate to verify the legality of the work order public key certificate of the acquirer in the APK after the signature;
- the credit application list file is stored to the terminal.
- the credit application list file will be stored in the terminal in the form of an APK, after the signature of the acquiring institution and the verification of the terminal to ensure that it is legally secure, and is used for determining whether the APK is credited or not.
- the credit application list is safe and reliable and has not been illegally tampered with.
- the “authentication of the validity of the APK by the terminal” is specifically:
- the terminal uses the acquirer root certificate to verify the legality of the work public key certificate stored in the APK;
- the terminal after obtaining an APK, the terminal first determines the legality by using the preset public key certificate of the acquirer, and only confirms that the APK is legal, and can be installed in the terminal, thereby ensuring the legitimacy of the program on the terminal device. .
- the credit application list file further includes an authorized application list file version, a creation time, an authorized APK list number, a package name of each authorized APK in the single authorized APK list, and a corresponding public key certificate.
- the version of the credit application list can be identified by the version, so that the subsequent high version can replace the lower version; the source attribute of the list can be traced by creating the time; the different credited APKs are identified by the special package name; Corresponding to the third-party public key certificate used by the developers of each credited APK, the verification of the system's original verification mechanism is implemented; at the same time, the package name and the public key certificate are used together as a basis for judging whether to be stored in the credit application list, and the judgment accuracy is improved. .
- FIG. 4 another technical solution provided by the present invention is:
- An Android-based APK download system that includes:
- the first signature module 1 is configured to sign the APK containing the credit application list file to obtain a signed APK, where the credit application list file includes a package name of each credit APK and a corresponding public key certificate;
- the first obtaining module 2 is configured to acquire, by the terminal, the APK after the signature;
- the first verification module 3 is configured to verify the validity of the APK after the signature
- the storage module 4 when the verification result of the first verification module is that the verification is passed, storing the credit application list file;
- a second verification module 5 configured to acquire an APK, and the terminal verifies the legality of the one APK
- the first judging module 6 is configured to determine whether the header of the one APK and the corresponding public key certificate are stored in the credit application list file when the verification result of the second verification module is not passed;
- the third verification module 7 is configured to verify the validity of the one APK by using an Android signature mechanism when the determination result of the first determination module is YES.
- the first signature module 1 includes:
- the first generating unit 11 is configured to generate an acquiring institution working public key certificate, and issue a public key corresponding to the working institution public key certificate to a different manufacturer;
- the first signing unit 12 is configured to: the acquiring institution uses the private key corresponding to the acquiring institution working public key certificate to sign the APK containing the credit application list file, and generate signature data;
- the second generating unit 13 is configured to generate a signed APK including the acquirer work public key certificate and the signature data.
- the first verification module 3 includes:
- the third generating unit 31 is configured to generate, by the different vendors, the acquirer root public key certificate by using the public key according to a respective certificate generation mechanism, and pre-installed in the respective terminal;
- the first verification unit 32 is configured to verify, by the terminal, the legitimacy of the work function public key certificate of the acquirer in the APK after using the acquirer root certificate;
- the second verification unit 33 is configured to verify the validity of the signature information by using an acquirer work public key certificate when the verification result of the first verification unit 32 is verification pass;
- the storage module 4, specifically for the verification result of the second verification unit 33, is verified, and then saves The credit application list file is stored to the terminal.
- the third verification module 71 includes:
- the third verification unit 71 is configured to verify, by the terminal, the legality of the working public key certificate stored in the APK by using the acquirer root certificate;
- the fourth verification unit 72 is configured to verify, by using the working public key certificate, the validity of the signature data in the one APK, if the verification result of the third verification unit 71 is verification pass;
- the fifth verification unit 73 is configured to verify the validity of the one APK by using an Android signature mechanism, if the verification result of the fourth verification unit is verification.
- the credit application list file further includes an authorized application list file version, a creation time, an authorized APK list number, a package name of each authorized APK in the single authorized APK list, and a corresponding public key certificate.
- the embodiment provides a method for downloading an APK based on an Android system, and the method may specifically include:
- the credit application list file includes an authorized application list file version, a creation time, an authorized APK list number, a package name of each authorized APK in a single authorized APK list, and a corresponding public key certificate.
- the credit application list file is placed in the original APK file, the file path is assets/trustedapp.list; the APK storing the credit application list file is the special package name: com.acquirer.trustedapplist; used to distinguish ordinary APKs.
- a specific credit application list file is:
- S1 may specifically include:
- the signing server of the acquiring institution invokes the encryption device to generate a first public private key pair and a second public private key pair, and the signing server of the acquiring institution uses the first private key to sign the second public key to generate an acquiring institution working public key.
- the CA server of different vendors generates the acquirer root public key certificate by using the first public key issued by the acquirer according to the respective certificate generation mechanism, and pre-installs the acquirer root public key certificate in the vendor's respective In the terminal device;
- the signing server of the acquiring institution will include the original APK file of the credit application list file; calculate the hash of the original APK file to obtain the first hash value HASH1;
- the signature server of the acquirer acquires a second private key corresponding to the work order public key certificate of the acquirer from the secure storage medium, and encrypts and signs the first hash value HASH1 by using the second private key to generate and receive Single agency signature data;
- S15 generating the signature APK after the acquiring institution signature description information, the acquiring institution signature data, and the acquiring institution working public key certificate;
- S2 the terminal acquires the signature after the APK
- the terminal device of different vendors can obtain the signed APK by automatic downloading or periodic self-test;
- S3 verifying the legality of the APK after the signature, and after verifying, storing the credit application list file; specifically, referring to FIG. 2, the following steps may be included:
- S31 determining, according to the package name of the APK, whether it is a special package name in which the credit application list is stored; if yes, executing S32; if not, executing S32, but not performing the step of storing the list to the terminal security module;
- S32 The terminal uses the acquirer root certificate in the pre-existing terminal to verify the legality of the work function public key certificate of the acquirer in the APK after the signature;
- the terminal uses the acquirer work public key certificate to extract the second public key, and uses the second public key to decrypt the acquirer signature data, and the decryption succeeds to obtain the first hash value HASH1;
- S33 The terminal calculates a hash of the original APK file, and obtains a second hash value HASH2;
- S34 Determine whether the second hash value HASH1 and the first hash value HASH2 are consistent. If the identifier is consistent, the APK after the signature obtained by the terminal is proved to be legal and has not been tampered with, and the verification of the APK by the vendor device after the signature is passed. Continue to use the native authentication mechanism of the Android system to check the validity of the original APK file; if passed, the terminal is allowed to install the original APK file; if not, the installation fails;
- the acquired APK is invalid after the signature, and may be tampered with and the installation fails.
- the Android system native verification mechanism may include:
- S35 The third-party APK developer uses the encryption machine to generate a third-party work public key certificate
- S36 Sign the developed APK file by using the private key corresponding to the third-party work public key certificate to generate development signature information
- S37 Generate an original APK file including the third-party work public key certificate and the development signature information
- the Android system acquires the third-party work public key certificate and the development signature information in the original APK file, and uses the third-party work public key certificate to verify the legality of the development signature information.
- the terminal downloads and obtains the credit application list file, and provides a basis for determining whether the credit application is directly used according to the credit application list file; and the credit application list file is signed by the acquiring institution and the terminal is checked. Security legality is guaranteed, which in turn ensures the accuracy of the credit card judgment.
- the terminal device can also obtain an APK by means of automatic download or periodic self-test; and verify the legality of the acquired APK; the legality verification can include the following:
- S41 The terminal first uses the acquirer root certificate in the pre-existing terminal to verify the legality of the work public key certificate stored in the acquired APK; if the verification is passed, S42 is executed, and the work public key certificate is proved to be the acquirer.
- Working public key certificate, and the working institution public key certificate is legal, the APK is signed by the acquiring institution; if the verification fails, the implementation of S43 proves that the working public key certificate is illegal, has been illegally tampered with, or
- the work public key certificate is not an employment agency public key certificate, and may be a third party work public key certificate.
- S42 The terminal uses the acquirer work public key certificate to verify the legality of the signature data in the APK;
- the verification If the verification is passed, it proves that the APK is legal and has not been tampered with. It is an APK that has been legally signed by the acquiring institution, and continues to use the Android system's native verification mechanism to check the legality of the APK; if the original verification is passed, the terminal is allowed. Install the APK file; if it does not pass, the installation fails;
- the APK when the terminal obtains an APK, the APK will be first legally signed by the existing, acquiring institution signature mechanism, and the default legality of the APK will be verified by using the preset acquiring institution root convention certificate;
- the signature verification process is more complicated and time-consuming, but it can ensure the legitimacy of the acquired APK.
- the APK cannot pass the terminal according to the acceptance mechanism of the acquirer, the APK and its working public key certificate are judged. Whether it exists in the credit application list, that is, whether the APK is a credit APK, and if so, the next system native check can be performed.
- the APK cannot be based on the acceptance mechanism of the acquirer through the terminal, it can also guarantee its legitimacy. It belongs to the already credited APK, which is also legal and trustworthy; thus eliminating the signature process of the APK through the acquirer, simplifying
- the upgrade process of the already-credited APK avoids the impact of the update process on the work of the terminal.
- Embodiment 2 of the present invention is:
- the embodiment provides an Android system APK download system based on the first embodiment, including:
- the first signature module 1 is configured to sign an APK including a credit application list file, and obtain a signed APK, where the credit application list file includes a package name of each credit APK and a corresponding public key certificate; the credit application list file is specific The license application list file version, the creation time, the number of authorized APK lists, the package name of each authorized APK in the single authorization APK list, and the corresponding public key certificate;
- the first signature module 1 includes:
- the first generating unit 11 is configured to generate an acquiring institution working public key certificate, and issue a public key corresponding to the working institution public key certificate to a different manufacturer;
- the first signing unit 12 is configured to: the acquiring institution uses the private key corresponding to the acquiring institution working public key certificate to sign the APK containing the credit application list file, and generate signature data;
- the second generating unit 13 is configured to generate a signed APK including the acquirer work public key certificate and the signature data.
- the first obtaining module 2 is configured to acquire, by the terminal, the APK after the signature;
- the first verification module 3 is configured to verify the validity of the APK after the signature
- the first verification module includes:
- the third generating unit 31 is configured to generate, by the different vendors, the acquirer root public key certificate by using the public key according to a respective certificate generation mechanism, and pre-installed in the respective terminal;
- the first verification unit 32 is configured to verify, by the terminal, the legitimacy of the work function public key certificate of the acquirer in the APK after using the acquirer root certificate;
- the second verification unit 33 is configured to verify the validity of the signature information by using an acquirer work public key certificate when the verification result of the first verification unit 32 is verification pass;
- the storage module 4 specifically for the verification result of the second verification unit 33, is the verification pass, and stores the credit application list file to the terminal.
- the storage module 4 is configured to: when the verification result of the first verification module 3 is verified, the credit application list file is stored;
- a second verification module 33 configured to acquire an APK, and the terminal verifies the legality of the one APK
- the first judging module 6 is configured to determine whether the header of the one APK and the corresponding public key certificate are stored in the credit application list file when the verification result of the second verification module 5 is not passed;
- the third verification module 7 is configured to verify the validity of the one APK by using an Android signature mechanism when the determination result of the first determination module 6 is YES.
- the third verification module 7 includes:
- the third verification unit 71 is configured to verify, by the terminal, the legality of the working public key certificate stored in the APK by using the acquirer root certificate;
- the fourth verification unit 72 is configured to verify, by using the working public key certificate, the validity of the signature data in the one APK, if the verification result of the third verification unit 71 is verification pass;
- the fifth verification unit 73 for the verification result of the fourth verification unit 72, is the verification pass, and then uses the Android signature mechanism to verify the validity of the one APK.
- the terminal devices in the first embodiment to the third embodiment are POS machines or other smart payment terminals.
- the present invention provides an Android system APK download method and system thereof, and solves the simple update and upgrade of the existing credited APK each time, and needs to re-pass the signature verification mechanism of the acquiring institution, thereby affecting the terminal.
- Problem with normal work by storing a list of trusted applications in the terminal, in none
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Stored Programmes (AREA)
Abstract
一种基于安卓***APK下载方法及其***,方法包括:对包含授信应用列表文件的APK进行签名,得到签名后APK,所述授信应用列表文件包括各个授信APK的包名和对应的公钥证书(S1);终端获取所述签名后APK(S2);验证所述签名后APK的合法性(S3),验证通过后,存储所述授信应用列表文件至终端;获取一APK(S4),终端验证所述一APK的合法性(S41);若验证不通过,则判断所述一APK的包头和对应的公钥证书是否存储于所述授信应用列表文件中(S43);若是,则继续使用安卓签名机制验证所述一APK的合法性(S45)。该方法增加授信应用列表文件,简化已授信APK下载安装的过程,进而简化授信APK的更新升级过程;减少应用更新升级对终端正常工作的影响。
Description
本发明涉及签名认证领域,具体说的是一种基于安卓***APK下载方法及其***。
Android安卓***是Google公司开发的基于Linux架构的开源操作***,其上的安装程序均为APK(Android Package)格式。
在金融支付领域,一般是由收单机构(如银行***)采购支付终端厂商(如各个POS机厂商)的智能终端设备(POS机),由收单***对支付终端进行集中管理,包括参数下载,密钥下载,接受、处理或转发支付终端的交易请求,并向支付终端回送交易结果信息,是集中管理和交易处理的***。收单***会在支付终端上安装自己的程序,并为支付终端设备维护已签名的APK,也可能需要将APK安装到其他Android设备中。
为了保证支付终端上程序的合法性,终端需要引入数字签名方案,在终端预置收单机构下发的根公钥证书,只有通过根公钥证书下属的工作公钥证书对应的私钥签名的APK才能安装到支付终端。若APK的版本等信息需要更新升级,则新升级的APK便需要重新通过收单方进行上述的签名后,才能被下载安装到支付终端。这样,即使是已经授信的APK,每次的更新升级都还是需要重新进行签名和验证,重复签名验证的过程加重了终端的工作负担,同时延长了APK更新升级所耗费的时间,耽误支付终端的正常工作。
公开号为CN101425114的中国专利,公开了一种软件升级包封装的方法,具体公开了包括以下步骤:a、软件升级包发行商确定需要对升级软件包进行验证的多个认证机构;b、升级软件明文经哈希运算后得到的信息摘要经多个认证机构的私钥分别进行加密,得到各认证机构的数字签名;c、软件升级包发行商将软件明文、各认证机构的数字签名和各认证机构的数字证书重新组合为软件升级包发送至终端设备。
上述更新安装还是需要经过认证机构的签名验证,仍然无法消除每次APK升级时都需要终端重新签名和验签而对终端正常工作带来的影响。
发明内容
本发明所要解决的技术问题是:提供一种基于安卓***APK下载方法及其***,在保证APK安全性的前提下,简化下载过程的验签流程,便于授信APK更新升级。
为了解决上述技术问题,本发明采用的技术方案为:
一种基于安卓***APK下载方法,包括:
对包含授信应用列表文件的APK进行签名,得到签名后APK,所述授信应用列表文件包括各个授信APK的包名和对应的公钥证书;
终端获取所述签名后APK;验证所述签名后APK的合法性,验证通过后,存储所述授信应用列表文件;
获取一APK,终端验证所述一APK的合法性;
若验证不通过,则判断所述一APK的包头和对应的公钥证书是否存储于所述授信应用列表文件中;
若是,则使用安卓签名机制验证所述一APK的合法性。
本发明提供的另一个技术方案为:
一种基于安卓***APK下载***,包括:
第一签名模块,用于对包含授信应用列表文件的APK进行签名,得到签名后APK,所述授信应用列表文件包括各个授信APK的包名和对应的公钥证书;
第一获取模块,用于终端获取所述签名后APK;
第一验证模块,用于验证所述签名后APK的合法性;
存储模块,用于第一验证模块的验证结果为验证通过时,存储所述授信应用列表文件;
第二验证模块,用于获取一APK,终端验证所述一APK的合法性;
第一判断模块,用于第二验证模块的验证结果为不通过时,判断所述一APK的包头和对应的公钥证书是否存储于所述授信应用列表文件中;
第三验证模块,用于第一判断模块的判断结果为是时,则使用安卓签名机制验证所述一APK的合法性。
本发明的有益效果在于:本发明的APK下载方法及其***,允许授信的APK不需要经过终端根公钥证书下属的工作公钥证书对应的私钥签名,就可以下载到终端。由于是授信的APK,因此能够确保该APK的来源可靠,符合安全性要求;与此同时,由于该APK的安全性已经得到肯定,便无需再经过收单机构的签名,以及终端依据收单机构根公钥证书的验签流程,安全可靠的授信APK能够直接下载安装到终端,大大简化了授信APK的更新升级过程;避免授信APK的更新升级影响终端的正常工作,同时减轻收单***以及终端的工作负担,又能确保安装的APK的合法性。
图1为本发明一种基于安卓***APK下载方法的方法流程示意图;
图2为本发明一种基于安卓***APK下载方法中包含授信应用列表的APK下载流程示意图;
图3为本发明一种基于安卓***APK下载方法中APK验签流程示意图;
图4为本发明一种基于安卓***APK下载***的功能模块组成示意图;
图5为本发明基于安卓***APK下载***中第一签名模块的组成示意图;
图6为本发明基于安卓***APK下载***中第一验证模块的组成示意图;
图7为本发明基于安卓***APK下载***中第三验证模块的组成示意图。
标号说明:
1、第一签名模块;2、第一获取模块;3、第一验证模块;
4、存储模块;5、第二验证模块;6、第一判断模块;7、第三验证模块;
11、第一生成单元;12、第一签名单元;13、第二生成单元;
31、第三生成单元;32、第一验证单元;33、第二验证单元;
71、第三验证单元;72、第四验证单元;73、第五验证单元。
本发明最关键的构思在于:将包含授信应用列表文件的APK按照现有签名验签机制下载到终端;判断无法通过收单机构验签机制的APK及其签名证书是否存储在授信应用列表中,判定该APK是否授信,只有授信的APK才继续进行***的原生验签。
请参照图1,本发明提供一种基于安卓***APK下载方法,包括:
对包含授信应用列表文件的APK进行签名,得到签名后APK,所述授信应用列表文件包括各个授信APK的包名和对应的公钥证书;
终端获取所述签名后APK;验证所述签名后APK的合法性,验证通过后,存储所述授信应用列表文件;
获取一APK,终端验证所述一APK的合法性;
若验证不通过,则判断所述一APK的包头和对应的公钥证书是否存储于所述授信应用列表文件中;
若是,则使用安卓签名机制验证所述一APK的合法性。
从上述描述可知,本发明的有益效果在于:终端预置收单机构根公钥证书,只有使用收单机构根公钥证书下属的收单机构工作公钥证书对应的私钥签名的APK或存在于授信应用列表中的APK才能下载到终端,保证非法的APK无法下载到终端支付设备,确保已下载APK的安全性。同时,已授信APK可以不需要经过终端根公钥证书下属的工作公钥证书对应的私钥签名,只要使用已授信的工作公钥证书及私钥签名,便可通过终端验证,可以下载到终端支付设备,便于授信APK的更新升级,免去已授信APK每次更新升级后都需要再经过收单机构签名验签的过程。
请参阅图2,进一步的,所述“对包含授信应用列表文件的APK进行签名,得到签名后APK”具体为:
收单机构生成收单机构工作公钥证书,下发收单机构工作公钥证书对应的公钥至不同厂商;
收单机构使用收单机构工作公钥证书对应的私钥对包含授信应用列表文件的APK进行签名,生成签名数据;
生成包含收单机构工作公钥证书以及所述签名数据的签名后APK。
进一步的,所述“验证所述签名后APK的合法性,验证通过后,存储所述授信应用列表文件”具体为:
不同厂商根据各自的证书生成机制使用所述公钥生成收单机构根公钥证书,并预装在各自的终端中;
终端使用收单机构根证书验证所述签名后APK中的收单机构工作公钥证书的合法性;
若验证通过,则使用收单机构工作公钥证书验证所述签名信息的合法性;
若验证通过,则存储所述授信应用列表文件至终端。
由上述描述可知,授信应用列表文件将以APK的形式,经过收单机构的签名,以及终端的验签,确保其合法安全后,才能被存储在终端中,用于APK是否授信的判断,保证了授信应用列表的安全可靠,未被非法篡改。
请参阅图3,进一步的,所述“终端验证所述一APK的合法性”具体为:
终端使用收单机构根证书验证所述一APK中存储的工作公钥证书的合法性;
若验证通过,则使用所述工作公钥证书验证所述一APK中的签名数据的合法性;
若验证通过,则使用安卓签名机制验证所述一APK的合法性。
由上述描述可知,终端获取到一APK后,首先使用预置的收单机构根公钥证书判断其合法性,只有确认该APK合法,才能安装在终端中,保证了终端设备上程序的合法性。
进一步的,所述授信应用列表文件还包括授权应用列表文件版本、创建时间、授权APK列表条数、单条授权APK列表中各个授权APK的包名以及对应的公钥证书。
由上述描述可知,通过版本可以识别所述授信应用列表的版本高低,便于后续高版本替换低版本;通过创建时间来追溯列表的源头属性;通过特殊的包名来识别不同的已授信APK;通过对应各个已授信APK的开发商所使用的第三方公钥证书,实现***原生验签机制的验签;同时将包名和公钥证书一起作为判断是否存储在授信应用列表的依据,提高判断精确度。
请参阅图4,本发明提供的另一个技术方案为:
一种基于安卓***APK下载***,包括:
第一签名模块1,用于对包含授信应用列表文件的APK进行签名,得到签名后APK,所述授信应用列表文件包括各个授信APK的包名和对应的公钥证书;
第一获取模块2,用于终端获取所述签名后APK;
第一验证模块3,用于验证所述签名后APK的合法性;
存储模块4,用于第一验证模块的验证结果为验证通过时,存储所述授信应用列表文件;
第二验证模块5,用于获取一APK,终端验证所述一APK的合法性;
第一判断模块6,用于第二验证模块的验证结果为不通过时,判断所述一APK的包头和对应的公钥证书是否存储于所述授信应用列表文件中;
第三验证模块7,用于第一判断模块的判断结果为是时,则使用安卓签名机制验证所述一APK的合法性。
请参阅图5,进一步的,所述第一签名模块1包括:
第一生成单元11,用于收单机构生成收单机构工作公钥证书,下发收单机构工作公钥证书对应的公钥至不同厂商;
第一签名单元12,用于收单机构使用收单机构工作公钥证书对应的私钥对包含授信应用列表文件的APK进行签名,生成签名数据;
第二生成单元13,用于生成包含收单机构工作公钥证书以及所述签名数据的签名后APK。
请参阅图6,进一步的,所述第一验证模块3包括:
第三生成单元31,用于不同厂商根据各自的证书生成机制使用所述公钥生成收单机构根公钥证书,并预装在各自的终端中;
第一验证单元32,用于终端使用收单机构根证书验证所述签名后APK中的收单机构工作公钥证书的合法性;
第二验证单元33,用于第一验证单元32的验证结果为验证通过,则使用收单机构工作公钥证书验证所述签名信息的合法性;
所述存储模块4,具体用于第二验证单元33的验证结果为验证通过,则存
储所述授信应用列表文件至终端。
请参阅图7,进一步的,所述第三验证模块71包括:
第三验证单元71,用于终端使用收单机构根证书验证所述一APK中存储的工作公钥证书的合法性;
第四验证单元72,用于第三验证单元71的验证结果为验证通过,则使用所述工作公钥证书验证所述一APK中的签名数据的合法性;
第五验证单元73,用于第四验证单元的验证结果为验证通过,则使用安卓签名机制验证所述一APK的合法性。
进一步的,所述授信应用列表文件还包括授权应用列表文件版本、创建时间、授权APK列表条数、单条授权APK列表中各个授权APK的包名以及对应的公钥证书。
实施例一
请参照图1-图3,本实施例提供一种基于安卓***APK下载方法,该方法具体可以包括:
S1:收单机构对包含授信应用列表文件的原始APK文件进行签名,得到签名后APK;
如下表所示,所述授信应用列表文件包括授权应用列表文件版本、创建时间、授权APK列表条数、单条授权APK列表中各个授权APK的包名以及对应的公钥证书。授信应用列表文件放在原始APK文件中,文件路径为assets/trustedapp.list;存储有授信应用列表文件的APK为特殊包名:com.acquirer.trustedapplist;用于区别普通的APK。
内容 | 说明 |
TrustedApp-Version | 授信应用列表文件版本 |
CreateTime | 创建时间 |
TrustedApp-Number | 授信应用列表条数 |
Name | 单条授信应用列表授信的APK的包名 |
SHA2-Digest-PubK | 单条授信应用列表授信的APK对应的公钥 |
ey | 证书HASH值,SHA256,经过Base64编码 |
Info | 备注信息 |
如一具体的授信应用列表文件为:
TrustedApp-Version:1
CreateTime:2016-01-01
TrustedApp-Number:2
Name:com.example.test
SHA2-Digest-PubKey:MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=
Info:test
Name:com.example2.test2
SHA2-Digest-PubKey:cTIzNDU2Nzg5MDFyZXc1Njc4OTAxMjM0NTY3ODkwMTI=
Info:
S1具体可以包括:
S11:收单机构的签名服务器调用加密设备生成第一公私钥对和第二公私钥对,收单机构的签名服务器使用第一私钥对第二公钥进行签名操作生成收单机构工作公钥证书,将第一公钥分发至不同厂商的CA服务器;
S12:不同厂商的CA服务器根据各自的证书生成机制使用收单机构下发的第一公钥生成收单机构根公钥证书,并将所述收单机构根公钥证书预装在厂商各自的终端设备中;
S13:收单机构的签名服务器将包含授信应用列表文件的原始APK文件;对原始APK文件计算哈希,获得第一哈希值HASH1;
S14:收单机构的签名服务器从安全存储介质中获取与收单机构工作公钥证书对应的第二私钥,并利用第二私钥对所述第一哈希值HASH1进行加密签名,生成收单机构签名数据;
S15:将收单机构签名描述信息、收单机构签名数据、收单机构工作公钥证书一起生成签名后APK;
S2:终端获取所述签名后APK;
具体的,不同厂商的终端设备可以通过自动下载或者周期自检的方式获取所述签名后APK;
S3:验证所述签名后APK的合法性,验证通过后,存储所述授信应用列表文件;具体的,请参阅图2,可以包括以下步骤:
S31:依据APK的包名判断是否为存储有授信应用列表的特殊包名;若是,则执行S32;若否,则同样执行S32,但不执行将列表存储至终端安全模块的步骤;
S32:终端使用预存在终端中的收单机构根证书验证所述签名后APK中的收单机构工作公钥证书的合法性;
若验证通过,则终端使用收单机构工作公钥证书提取第二公钥,使用第二公钥解密所述收单机构签名数据,解密成功,获得第一哈希值HASH1;
S33:终端对原始APK文件计算哈希,得到第二哈希值HASH2;
S34:判断所述第二哈希值HASH1与第一哈希值HASH2是否一致,若一致,则证明终端所获取到的签名后APK合法,未被篡改,厂商设备对签名后APK的验证通过,继续使用安卓***原生验签机制验签所述原始APK文件的合法性;若通过,则允许终端安装所述原始APK文件;若不通过,则安装失败;
若不一致,则所述获取的签名后APK不合法,可能被篡改,安装失败;
具体的,所述安卓***原生验签机制可以包括:
原生签名流程:
S35:第三方APK开发商使用加密机生成第三方工作公钥证书;
S36:使用所述第三方工作公钥证书对应的私钥对所开发的APK文件进行签名,生成开发签名信息;
S37:生成包含所述第三方工作公钥证书以及所述开发签名信息的原始APK文件;
原生验签流程:
S38:安卓***获取所述原始APK文件中的第三方工作公钥证书和所述开发签名信息;使用所述第三方工作公钥证书验证所述开发签名信息的合法性;
若验证通过,则执行S39;
S39:安装所述原始APK文件,存储其中的所述授信应用列表文件至终端。
通过上述步骤,便完成了终端下载获取授信应用列表文件,为后续直接依据授信应用列表文件判断是否为授信APK提供依据;且所述授信应用列表文件经过收单机构的签名,以及终端的验签,安全合法性得到保证,进而能够确保授信APK判断的准确性。
请结合图3,下述为终端在获取任意一APK时候的验签流程:
S4:终端设备同样可以通过自动下载或者周期自检的方式获取一APK;并对所获取的APK进行合法性验证;合法性验证可以包括以下:
S41:终端首先使用预存在终端中的收单机构根证书验证所获取的APK中存储的工作公钥证书的合法性;若验证通过,执行S42,同时证明所述工作公钥证书为收单机构工作公钥证书,且该收单机构工作公钥证书合法,所述APK经过收单机构的签名;若验证不通过,则执行S43证明所述工作公钥证书不合法,被非法篡改过,或者所述工作公钥证书并非收单机构工作公钥证书,可能是第三方工作公钥证书。
S42:终端使用收单机构工作公钥证书验证该APK中的签名数据的合法性;
若验证通过,则证明该APK合法,未被篡改,是经过收单机构的合法签名的APK,继续使用安卓***原生验签机制验签该APK的合法性;若原生验签通过,则允许终端安装该APK文件;若不通过,则安装失败;
若验证不通过,则执行S43,证明该APK可能被非法篡改,或者未经过收单机构的签名机制签名;
S42中具体的终端对APK的验签过程以及安卓***的原生验签过程与上述S32-S34以及S35-S39类似,在此不重复累述。
S43:获取所述APK中的工作公钥证书,以及对应的包头;
S44:判断所述APK的包头以及工作公钥证书是否存储在终端的授信应用列表文件中;若有,则执行S45;若没有,则执行S46;
S45:判定所述APK为授信APK,继续使用安卓签名机制验证所述一APK的合法性;
S46:提示安装失败;证明所述APK既不是授信APK,又没有经过收单机构的合法签名,属于非法APK。
通过上述,当终端获取到一APK后,将首先默认所述APK经过现有的,收单机构签名机制进行合法签名,使用预置的收单机构根公约证书对APK合法性进行验证;虽然APK的签名验签过程较为复杂、耗时,却能确保所获取到的APK的合法性;而当APK无法通过终端依据收单机构的验签机制时,再判断所述APK及其工作公钥证书是否存在于授信应用列表中,即判断该APK是否为授信APK,若是,则可以进行下一步的***原生验签。虽然该APK无法通过终端基于收单机构的验签机制,却同样能够保证其合法性,属于已经授信的APK,同样合法可信任;由此省去了APK通过收单机构的签名过程,简化了已经授信的APK的更新升级过程,避免更新升级过程对终端的工作带来影响。
本发明的实施例二为:
请参照图4,本实施例基于实施例一提供一种安卓***APK下载***,包括:
第一签名模块1,用于对包含授信应用列表文件的APK进行签名,得到签名后APK,所述授信应用列表文件包括各个授信APK的包名和对应的公钥证书;所述授信应用列表文件具体包括授权应用列表文件版本、创建时间、授权APK列表条数、单条授权APK列表中各个授权APK的包名以及对应的公钥证书;
具体的,请参阅图5,所述第一签名模块1包括:
第一生成单元11,用于收单机构生成收单机构工作公钥证书,下发收单机构工作公钥证书对应的公钥至不同厂商;
第一签名单元12,用于收单机构使用收单机构工作公钥证书对应的私钥对包含授信应用列表文件的APK进行签名,生成签名数据;
第二生成单元13,用于生成包含收单机构工作公钥证书以及所述签名数据的签名后APK。
第一获取模块2,用于终端获取所述签名后APK;
第一验证模块3,用于验证所述签名后APK的合法性;
具体的,请参阅图6,所述第一验证模块包括:
第三生成单元31,用于不同厂商根据各自的证书生成机制使用所述公钥生成收单机构根公钥证书,并预装在各自的终端中;
第一验证单元32,用于终端使用收单机构根证书验证所述签名后APK中的收单机构工作公钥证书的合法性;
第二验证单元33,用于第一验证单元32的验证结果为验证通过,则使用收单机构工作公钥证书验证所述签名信息的合法性;
所述存储模块4,具体用于第二验证单元33的验证结果为验证通过,则存储所述授信应用列表文件至终端。
存储模块4,用于第一验证模块3的验证结果为验证通过时,存储所述授信应用列表文件;
第二验证模块33,用于获取一APK,终端验证所述一APK的合法性;
第一判断模块6,用于第二验证模块5的验证结果为不通过时,判断所述一APK的包头和对应的公钥证书是否存储于所述授信应用列表文件中;
第三验证模块7,用于第一判断模块6的判断结果为是时,则使用安卓签名机制验证所述一APK的合法性。
具体的,请参阅图7,所述第三验证模块7包括:
第三验证单元71,用于终端使用收单机构根证书验证所述一APK中存储的工作公钥证书的合法性;
第四验证单元72,用于第三验证单元71的验证结果为验证通过,则使用所述工作公钥证书验证所述一APK中的签名数据的合法性;
第五验证单元73,用于第四验证单元72的验证结果为验证通过,则使用安卓签名机制验证所述一APK的合法性。
实施例一至实施例三中的终端设备为POS机或者其他智能支付终端。
综上所述,本发明提供的一种基于安卓***APK下载方法及其***,解决现有的已授信APK每次的简单更新升级都需要重新经过收单机构的签名验签机制,从而影响终端的正常工作的问题;通过在终端存储有授信应用列表,在无
法通过终端基于收单机构的验签时,只需判断APK及其工作公钥证书是否存储在授信应用列表中,便可判定APK是否为已授信APK,已授信APK直接跳过收单机构的验签,进入***原生验签过程,从而大大简化了授信APK的更新升级过程;避免授信APK的更新升级影响终端的正常工作,同时减轻收单***以及终端的工作负担,又能确保安装的APK的合法性。
Claims (10)
- 一种基于安卓***APK下载方法,其特征在于,包括:对包含授信应用列表文件的APK进行签名,得到签名后APK,所述授信应用列表文件包括各个授信APK的包名和对应的公钥证书;终端获取所述签名后APK;验证所述签名后APK的合法性,验证通过后,存储所述授信应用列表文件;获取一APK,终端验证所述一APK的合法性;若验证不通过,则判断所述一APK的包头和对应的公钥证书是否存储于所述授信应用列表文件中;若是,则使用安卓签名机制验证所述一APK的合法性。
- 如权利要求1所述的一种基于安卓***APK下载方法,其特征在于,所述“对包含授信应用列表文件的APK进行签名,得到签名后APK”具体为:收单机构生成收单机构工作公钥证书,下发收单机构工作公钥证书对应的公钥至不同厂商;收单机构使用收单机构工作公钥证书对应的私钥对包含授信应用列表文件的APK进行签名,生成签名数据;生成包含收单机构工作公钥证书以及所述签名数据的签名后APK。
- 如权利要求2所述的一种基于安卓***APK下载方法,其特征在于,所述“验证所述签名后APK的合法性,验证通过后,存储所述授信应用列表文件”具体为:不同厂商根据各自的证书生成机制使用所述公钥生成收单机构根公钥证书,并预装在各自的终端中;终端使用收单机构根证书验证所述签名后APK中的收单机构工作公钥证书的合法性;若验证通过,则使用收单机构工作公钥证书验证所述签名信息的合法性;若验证通过,则存储所述授信应用列表文件至终端。
- 如权利要求3所述的一种基于安卓***APK下载方法,其特征在于,所述“终端验证所述一APK的合法性”具体为:终端使用收单机构根证书验证所述一APK中存储的工作公钥证书的合法性;若验证通过,则使用所述工作公钥证书验证所述一APK中的签名数据的合法性;若验证通过,则使用安卓签名机制验证所述一APK的合法性。
- 如权利要求1-4任意一项所述的一种基于安卓***APK下载方法,其特征在于,所述授信应用列表文件具体包括授权应用列表文件版本、创建时间、授权APK列表条数、单条授权APK列表中各个授权APK的包名以及对应的公钥证书。
- 一种基于安卓***APK下载***,其特征在于,包括:第一签名模块,用于对包含授信应用列表文件的APK进行签名,得到签名后APK,所述授信应用列表文件包括各个授信APK的包名和对应的公钥证书;第一获取模块,用于终端获取所述签名后APK;第一验证模块,用于验证所述签名后APK的合法性;存储模块,用于第一验证模块的验证结果为验证通过时,存储所述授信应用列表文件;第二验证模块,用于获取一APK,终端验证所述一APK的合法性;第一判断模块,用于第二验证模块的验证结果为不通过时,判断所述一APK的包头和对应的公钥证书是否存储于所述授信应用列表文件中;第三验证模块,用于第一判断模块的判断结果为是时,则使用安卓签名机制验证所述一APK的合法性。
- 依据权利要求6所述的一种基于安卓***APK下载***,其特征在于,所述第一签名模块包括:第一生成单元,用于收单机构生成收单机构工作公钥证书,下发收单机构工作公钥证书对应的公钥至不同厂商;第一签名单元,用于收单机构使用收单机构工作公钥证书对应的私钥对包含授信应用列表文件的APK进行签名,生成签名数据;第二生成单元,用于生成包含收单机构工作公钥证书以及所述签名数据的签名后APK。
- 依据权利要求7所述的一种基于安卓***APK下载***,其特征在于, 所述第一验证模块包括:第三生成单元,用于不同厂商根据各自的证书生成机制使用所述公钥生成收单机构根公钥证书,并预装在各自的终端中;第一验证单元,用于终端使用收单机构根证书验证所述签名后APK中的收单机构工作公钥证书的合法性;第二验证单元,用于第一验证单元的验证结果为验证通过,则使用收单机构工作公钥证书验证所述签名信息的合法性;所述存储模块,具体用于第二验证单元的验证结果为验证通过,则存储所述授信应用列表文件至终端。
- 依据权利要求8所述的一种基于安卓***APK下载***,其特征在于,所述第三验证模块包括:第三验证单元,用于终端使用收单机构根证书验证所述一APK中存储的工作公钥证书的合法性;第四验证单元,用于第三验证单元的验证结果为验证通过,则使用所述工作公钥证书验证所述一APK中的签名数据的合法性;第五验证单元,用于第四验证单元的验证结果为验证通过,则使用安卓签名机制验证所述一APK的合法性。
- 依据权利要求6-9任意一项所述的一种基于安卓***APK下载***,其特征在于,所述授信应用列表文件具体包括授权应用列表文件版本、创建时间、授权APK列表条数、单条授权APK列表中各个授权APK的包名以及对应的公钥证书。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2016101825547 | 2016-03-28 | ||
CN201610182554.7A CN105787357B (zh) | 2016-03-28 | 2016-03-28 | 一种基于安卓***apk下载方法及其*** |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2017166561A1 true WO2017166561A1 (zh) | 2017-10-05 |
Family
ID=56390965
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2016/093437 WO2017166561A1 (zh) | 2016-03-28 | 2016-08-05 | 一种基于安卓***apk下载方法及其*** |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN105787357B (zh) |
WO (1) | WO2017166561A1 (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112395596A (zh) * | 2020-11-06 | 2021-02-23 | 广东天波信息技术股份有限公司 | 基于安卓***的防切机应用安装方法及装置 |
CN113609529A (zh) * | 2021-07-16 | 2021-11-05 | 苏州浪潮智能科技有限公司 | 一种计算机固件安全供应的方法、*** |
CN117093245A (zh) * | 2023-10-18 | 2023-11-21 | 湖北芯擎科技有限公司 | Ota升级包验证方法、装置、设备及可读存储介质 |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105787357B (zh) * | 2016-03-28 | 2019-01-04 | 福建联迪商用设备有限公司 | 一种基于安卓***apk下载方法及其*** |
CN108092947B (zh) * | 2016-11-23 | 2020-12-04 | 腾讯科技(深圳)有限公司 | 一种对第三方应用进行身份鉴别的方法及装置 |
WO2018119608A1 (zh) * | 2016-12-26 | 2018-07-05 | 华为技术有限公司 | 应用处理方法、网络设备及终端设备 |
CN106656513B (zh) * | 2017-02-24 | 2019-09-13 | 福建魔方电子科技有限公司 | 安卓平台上apk文件的二次打包签名验证方法 |
CN107391166B (zh) * | 2017-06-05 | 2022-01-25 | 深圳市优***科技股份有限公司 | Android应用的安装方法及***、计算机装置和可读存储介质 |
CN107506207B (zh) * | 2017-07-07 | 2021-04-20 | 上海汇尔通信息技术有限公司 | 一种pos机的安全验证方法及终端 |
US10715498B2 (en) * | 2017-07-18 | 2020-07-14 | Google Llc | Methods, systems, and media for protecting and verifying video files |
CN107958150A (zh) * | 2017-12-05 | 2018-04-24 | 中科信息安全共性技术国家工程研究中心有限公司 | 一种检测安卓热补丁安全性的方法 |
CN109450883B (zh) * | 2018-10-26 | 2021-08-27 | 北京梆梆安全科技有限公司 | 一种数字证书的破解风险检测方法及装置 |
CN111176685A (zh) * | 2019-12-27 | 2020-05-19 | 深圳市优必选科技股份有限公司 | 一种升级方法及装置 |
CN111695109B (zh) * | 2020-06-02 | 2024-04-26 | 中国工商银行股份有限公司 | 收单程序访问控制方法、收单终端及服务器 |
CN112134711B (zh) * | 2020-09-24 | 2021-05-07 | 深圳市捷诚技术服务有限公司 | Apk签名信息的安全验证方法、装置以及pos机 |
CN115879098B (zh) * | 2023-02-20 | 2023-05-05 | 北京麟卓信息科技有限公司 | 一种基于原子事务操作的安卓应用安装优化方法 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101425114A (zh) * | 2008-12-12 | 2009-05-06 | 四川长虹电器股份有限公司 | 软件升级包封装方法以及软件升级方法 |
US20140007075A1 (en) * | 2012-06-27 | 2014-01-02 | Google Inc. | Methods for updating applications |
CN103905207A (zh) * | 2014-04-23 | 2014-07-02 | 福建联迪商用设备有限公司 | 一种统一apk签名的方法及其*** |
CN103944903A (zh) * | 2014-04-23 | 2014-07-23 | 福建联迪商用设备有限公司 | 一种多方授权的apk签名方法及*** |
CN105391717A (zh) * | 2015-11-13 | 2016-03-09 | 福建联迪商用设备有限公司 | 一种apk签名认证方法及其*** |
CN105787357A (zh) * | 2016-03-28 | 2016-07-20 | 福建联迪商用设备有限公司 | 一种基于安卓***apk下载方法及其*** |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104639506B (zh) * | 2013-11-13 | 2018-07-24 | 中国电信股份有限公司 | 对应用程序安装进行管控的方法、***与终端 |
-
2016
- 2016-03-28 CN CN201610182554.7A patent/CN105787357B/zh active Active
- 2016-08-05 WO PCT/CN2016/093437 patent/WO2017166561A1/zh active Application Filing
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101425114A (zh) * | 2008-12-12 | 2009-05-06 | 四川长虹电器股份有限公司 | 软件升级包封装方法以及软件升级方法 |
US20140007075A1 (en) * | 2012-06-27 | 2014-01-02 | Google Inc. | Methods for updating applications |
CN103905207A (zh) * | 2014-04-23 | 2014-07-02 | 福建联迪商用设备有限公司 | 一种统一apk签名的方法及其*** |
CN103944903A (zh) * | 2014-04-23 | 2014-07-23 | 福建联迪商用设备有限公司 | 一种多方授权的apk签名方法及*** |
CN105391717A (zh) * | 2015-11-13 | 2016-03-09 | 福建联迪商用设备有限公司 | 一种apk签名认证方法及其*** |
CN105787357A (zh) * | 2016-03-28 | 2016-07-20 | 福建联迪商用设备有限公司 | 一种基于安卓***apk下载方法及其*** |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112395596A (zh) * | 2020-11-06 | 2021-02-23 | 广东天波信息技术股份有限公司 | 基于安卓***的防切机应用安装方法及装置 |
CN113609529A (zh) * | 2021-07-16 | 2021-11-05 | 苏州浪潮智能科技有限公司 | 一种计算机固件安全供应的方法、*** |
CN113609529B (zh) * | 2021-07-16 | 2023-07-18 | 苏州浪潮智能科技有限公司 | 一种计算机固件安全供应的方法、*** |
CN117093245A (zh) * | 2023-10-18 | 2023-11-21 | 湖北芯擎科技有限公司 | Ota升级包验证方法、装置、设备及可读存储介质 |
CN117093245B (zh) * | 2023-10-18 | 2024-01-16 | 湖北芯擎科技有限公司 | Ota升级包验证方法、装置、设备及可读存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN105787357A (zh) | 2016-07-20 |
CN105787357B (zh) | 2019-01-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2017166561A1 (zh) | 一种基于安卓***apk下载方法及其*** | |
US11870915B2 (en) | Unified programming environment for programmable devices | |
US10992482B2 (en) | Verified boot and key rotation | |
JP6263643B2 (ja) | 多者間信用照会のapk署名方法及びシステム | |
CN103685138B (zh) | 移动互联网上的Android平台应用软件的认证方法和*** | |
CN107463806B (zh) | 一种Android应用程序安装包的签名和验签方法 | |
JP5178341B2 (ja) | オプショナルなコンポーネントを伴うセキュアブートの方法 | |
JP6263644B2 (ja) | Apk署名を統一する方法及びそのシステム | |
US20170270319A1 (en) | Method and device for providing verifying application integrity | |
WO2022160733A1 (zh) | 一种文件签名方法、计算设备及存储介质 | |
JP2018503153A (ja) | アプリケーションのインテグリティを確かめることを提供する方法及びデバイス | |
US20170262657A1 (en) | Method and device for providing verifying application integrity | |
US20090287917A1 (en) | Secure software distribution | |
CN101226569A (zh) | 在虚拟机中验证代码模块的方法及装置 | |
KR20110050488A (ko) | 티켓 인증 보안 설치 및 부트 | |
US20170262658A1 (en) | Method and device for providing verifying application integrity | |
US8751811B2 (en) | Integrated circuit and system for installing computer code thereon | |
JP2023512428A (ja) | ハードウェアエンクレーブを使用して商用オフザシェルフプログラムバイナリを盗用から保護すること | |
WO2019080110A1 (zh) | 一种 apk 签名认证方法及*** | |
CN110018841A (zh) | 一种uefi bios升级方法、***及相关装置 | |
WO2017008728A1 (zh) | 一种划分终端开发模式和产品模式的方法及*** | |
JP6387908B2 (ja) | 認証システム | |
CN109670289B (zh) | 一种识别后台服务器合法性的方法及*** | |
England et al. | Towards a programmable TPM |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 16896333 Country of ref document: EP Kind code of ref document: A1 |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 16896333 Country of ref document: EP Kind code of ref document: A1 |