CN106096381A - 应用程序文件验证的方法及*** - Google Patents
应用程序文件验证的方法及*** Download PDFInfo
- Publication number
- CN106096381A CN106096381A CN201610395335.7A CN201610395335A CN106096381A CN 106096381 A CN106096381 A CN 106096381A CN 201610395335 A CN201610395335 A CN 201610395335A CN 106096381 A CN106096381 A CN 106096381A
- Authority
- CN
- China
- Prior art keywords
- check code
- application file
- authority
- authority information
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
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/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
Abstract
本发明公开了一种应用程序文件验证的方法及***,该方法包括:移动设备获取应用程序文件的第一校验码和第二校验码,第一校验码是根据所述应用程序文件本身携带的第一授权文件信息得到的,所述第二校验码是根据所述应用程序文件的正版携带的第二授权文件信息得到的;所述移动设备在所述第一校验码和所述第二校验码一致时,确定所述应用程序文件通过验证。通过上述方式,本发明能够在移动端确定应用程序文件的安全性,且不用输入较长的代码。
Description
技术领域
本发明涉及应用程序文件安全技术领域,特别是涉及一种应用程序文件验证的方法及***。
背景技术
安卓(Android)应用程序正面临严重的盗版问题,被盗版的应用程序可能被植入病毒、广告,还可能被二次打包以及篡改,这些都严重损害了应用程序的开发者以及消费者的权益。
针对这一情况,移动互联网的各个产业链都在做一些努力,来保护Android应用程序的安全。目前,普遍采用的软件授权的方式是在软件授权界面输入激活码或注册码完成注册,激活码或者注册码一般以"-"分隔,如Windows、Office等,例如Office2013:激活码是GQKNX-C6 T4B-V2T69-777QJ-XWYG7;又如Win10的安装激活码是NKJFK-GPHP 7-G8C3J-P6JXR-HQRJR;又如UltraEdit的注册码是Name:jialei_wy,激活码是:DSQOQ-OSPNA-JIHHK-TNVIO-ONFGK-EERGI-QOMRC-L QJAK。
上述保证Android应用程序安全的方法中,一方面,激活码或注册码较长,在移动端输入较困难,另一方面,注册码或激活码流出后,依然很容易被盗版。
发明内容
本发明主要解决的技术问题是提供一种应用程序文件验证的方法及***,能够在移动端确定应用程序文件的安全性,且不用输入较长的代码。
为解决上述技术问题,本发明采用的一个技术方案是:提供一种应用程序文件验证的方法,所述方法包括:移动设备获取应用程序文件的第一校验码和第二校验码,其中,所述第一校验码是根据所述应用程序文件本身携带的第一授权文件信息得到的,所述第二校验码是根据所述应用程序文件的正版携带的第二授权文件信息得到的;所述移动设备在所述第一校验码和所述第二校验码一致时,确定所述应用程序文件通过验证。
其中,所述第一授权文件信息为第一签名信息,所述第二授权文件信息为第二签名信息;所述移动设备获取所述应用程序文件的第一校验码和第二校验码的步骤之前,还包括:服务器通过散列算法对所述应用程序文件的正版已设置的所述第二签名信息进行计算,得到所述第二校验码;所述移动设备获取所述应用程序文件的第一校验码和第二校验码的步骤,包括:所述移动设备在所述应用程序文件启动时,通过网络连接服务器,进而从所述服务器获得所述应用程序文件的第二校验码,或,所述移动设备在所述应用程序文件启动时,获取内置在所述应用程序文件的所述第二校验码,所述移动设备通过所述散列算法对所述应用程序文件本身携带的所述第一签名信息进行计算,得到所述第一校验码。
其中,所述第二授权文件信息包括与所述应用程序文件的正版对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息;所述第一授权文件信息包括与所述应用程序文件对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息。
其中,所述移动设备获取应用程序文件的第一校验码和第二校验码的步骤之前,还包括:服务器生成与所述应用程序文件的正版对应的文本格式的所述第二授权文件信息;所述服务器通过散列算法对所述第二授权文件信息进行计算,得到授权校验码,所述授权校验码即为所述第二校验码;所述移动设备获取应用程序文件的第一校验码和第二校验码的步骤,包括:所述移动设备获取授权文件包,所述授权文件包中包括所述第二校验码的信息;所述移动设备通过所述散列算法对所述应用程序文件本身携带的所述第一授权文件信息进行计算,得到所述第一校验码。
其中,所述服务器通过散列算法对所述第二授权文件信息进行计算,得到授权校验码的步骤之后,还包括:所述服务器通过非对称加密算法生成公钥和私钥;所述服务器使用所述私钥对所述授权校验码加密,生成授权文件签名;所述第二校验码的信息为所述授权文件签名,所述移动设备获取应用程序文件的第一校验码和第二校验码的步骤,还包括:所述移动设备获取内置在所述应用程序文件的所述公钥;所述移动设备通过所述公钥对所述授权文件签名进行解密,获得所述授权验证码,所述授权验证码即为所述第二校验码。
其中,所述授权文件包中还包括所述第二授权文件信息,所述第二授权文件信息、所述第一授权文件信息中每个类别的授权信息均对应一个授权项;所述移动设备在所述第一校验码和所述第二校验码一致时,确定所述应用程序文件通过验证,包括:在所述第一校验码和所述第二校验码一致时,所述移动设备将所述第二授权文件信息中每个授权项分别与所述第一授权文件信息中对应的授权项进行比对,若所述第二授权文件信息中每个授权项与所述第一授权文件信息中对应的授权项都匹配,则确定所述应用程序文件通过验证。
为解决上述技术问题,本发明采用的另一个技术方案是:提供一种应用程序文件验证的***,所述***包括:移动设备,所述移动设备包括:获取模块,用于获取应用程序文件的第一校验码和第二校验码,其中,所述第一校验码是根据所述应用程序文件本身携带的第一授权文件信息得到的,所述第二校验码是根据所述应用程序文件的正版携带的第二授权文件信息得到的;确定模块,用于在所述第一校验码和所述第二校验码一致时,确定所述应用程序文件通过验证。
其中,所述第一授权文件信息为第一签名信息,所述第二授权文件信息为第二签名信息;所述***还包括:服务器,所述服务器包括:第一计算模块,用于通过散列算法对所述应用程序文件的正版已设置的所述第二签名信息进行计算,得到所述第二校验码;所述获取模块具体用于:在所述应用程序文件启动时,通过网络连接服务器,进而从所述服务器获得所述应用程序文件的第二校验码,或,在所述应用程序文件启动时,获取内置在所述应用程序文件的所述第二校验码;
通过所述散列算法对所述应用程序文件本身携带的所述第一签名信息进行计算,得到所述第一校验码。
其中,所述第二授权文件信息包括与所述应用程序文件的正版对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息;所述第一授权文件信息包括与所述应用程序文件对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息。
其中,所述***还包括:服务器,所述服务器包括:第一生成模块,用于生成与所述应用程序文件的正版对应的文本格式的所述第二授权文件信息;第二计算模块,用于通过散列算法对所述第二授权文件信息进行计算,得到授权校验码,所述授权校验码即为所述第二校验码;所述获取模块具体用于:获取授权文件包,所述授权文件包中包括所述第二校验码的信息;通过所述散列算法对所述应用程序文件本身携带的所述第一授权文件信息进行计算,得到所述第一校验码。
其中,所述服务器还包括:第二生成模块,用于通过非对称加密算法生成公钥和私钥;第三生成模块,用于使用所述私钥对所述授权校验码加密,生成授权文件签名;所述第二校验码的信息为所述授权文件签名,所述获取模块还用于:获取内置在所述应用程序文件的所述公钥;通过所述公钥对所述授权文件签名进行解密,获得所述授权验证码,所述授权验证码即为所述第二校验码。
其中,所述授权文件包中还包括所述第二授权文件信息,所述第二授权文件信息、所述第一授权文件信息中每个类别的授权信息均对应一个授权项;所述确定模块还用于在所述第一校验码和所述第二校验码一致时,将所述第二授权文件信息中每个授权项分别与所述第一授权文件信息中对应的授权项进行比对,若所述第二授权文件信息中每个授权项与所述第一授权文件信息中对应的授权项都匹配,则确定所述应用程序文件通过验证。
本发明的有益效果是:区别于现有技术的情况,本发明移动设备获取应用程序文件的第一校验码和第二校验码,第一校验码是根据所述应用程序文件本身携带的第一授权文件信息得到的,所述第二校验码是根据所述应用程序文件的正版携带的第二授权文件信息得到的;所述移动设备在所述第一校验码和所述第二校验码一致时,确定所述应用程序文件通过验证。由于应用程序文件的正版携带的第二授权文件信息,应用程序文件本身携带第一授权文件信息,当应用程序文件没有被篡改时,第一授权文件信息和第二授权文件信息是一致的,第一校验码和第二校验码也是一致的,当应用程序文件被篡改后,第一授权文件信息和第二授权文件信息是不一致的,第一校验码和第二校验码也不一致,通过这种方式,能够在移动端确定应用程序文件的安全性,且不用输入较长的代码。
附图说明
图1是本发明应用程序文件验证的方法一实施方式的流程图;
图2是本发明应用程序文件验证的方法另一实施方式的流程图;
图3是本发明应用程序文件验证的方法又一实施方式的流程图;
图4是本发明应用程序文件验证的方法又一实施方式的流程图;
图5是本发明应用程序文件验证的方法又一实施方式的流程图;
图6是本发明应用程序文件验证的***一实施方式的结构示意图;
图7是本发明应用程序文件验证的***另一实施方式的结构示意图;
图8是本发明应用程序文件验证的***又一实施方式的结构示意图;
图9是本发明应用程序文件验证的***又一实施方式的结构示意图。
具体实施方式
下面结合附图和实施方式对本发明进行详细说明。
参阅图1,图1是本发明应用程序文件验证的方法一实施方式的流程图,包括:
步骤S101:移动设备获取应用程序文件的第一校验码和第二校验码,其中,第一校验码是根据应用程序文件本身携带的第一授权文件信息得到的,第二校验码是根据应用程序文件的正版携带的第二授权文件信息得到的,所述应用程序文件的正版携带的第二授权文件信息即所述应用程序文件的正版对应的授权文件信息。移动设备获取应用程序文件的第一校验码和第二校验码也可以包括两个独立的步骤,即包括:移动设备获取应用程序文件的第一校验码的步骤、移动设备获取应用程序文件的第二校验码的步骤。
应用程序文件,在发行之后,或者被盗版,或者用户在使用的过程中,被篡改,这些均导致用户体验降低。现有技术中,通常是通过输入激活码或注册码的方式,来保证应用程序文件是正版而非盗版。但是,一方面,对于移动设备来说,输入长代码很不方便,另一方面,激活码或注册码也会被篡改。
在本发明实施方式中,当应用程序文件对应的正版产生后,即产生对应的第二授权文件信息,第二授权文件信息是指与应用程序文件的正版一一对应的授权文件信息,例如:设定的唯一的签名、设备序列号、应用程序文件包名、确定的唯一的时间信息等。该第二授权文件信息附着在应用程序文件对应的正版中。如果第二授权文件信息被篡改,则表明该应用程序文件已经被篡改。第二授权文件信息通常是应用开发商或应用开发商授权的服务商来确定。
第一授权文件信息是指对应于第二授权文件信息、与应用程序文件本身一一对应的授权文件信息。例如,如果第二授权文件信息是设定的唯一签名,那么第一授权文件信息也是对应的签名,只不过该签名有可能与设定的唯一签名一致,有可能在应用程序文件使用时被篡改而与设定的唯一签名不一致,或者应用程序文件本来就是盗版,签名自然也是与设定的唯一签名不一致。
根据应用程序文件本身携带的第一授权文件信息通过一定的方法获得第一校验码,根据应用程序文件的正版携带的第二授权文件信息通过一定的方法获得第二校验码。其中,获得第一校验码的方法和获得第二校验码的方法可以相同,也可以不相同,不相同的时候,需要确定第一校验码和第二校验码之间的对应关系,以确定第一校验码和第二校验码是否一致。
步骤S102:移动设备在第一校验码和第二校验码一致时,确定应用程序文件通过验证。
比较第一校验码和第二校验码,如果第一校验码和第二校验码一致,确定该应用程序文件通过验证,也即是该应用程序文件与应用程序文件的正版是一致的,该应用程序文件没有被篡改,授权是有效的。当然,该应用程序文件的正版在后续使用过程后,依然有可能被篡改,如果后续使用过程中被篡改,则第一校验码和第二校验码就不一致了。
如果第一校验码和第二校验码不一致,提示用户应用程序文件已经被篡改,继续使用有风险,或者应用程序文件为盗版,并引导用户使用应用程序文件的官方正版。
本发明实施方式移动设备获取应用程序文件的第一校验码和第二校验码,第一校验码是根据所述应用程序文件本身携带的第一授权文件信息得到的,所述第二校验码是根据所述应用程序文件的正版携带的第二授权文件信息得到的;所述移动设备在所述第一校验码和所述第二校验码一致时,确定所述应用程序文件通过验证。由于应用程序文件的正版携带的第二授权文件信息,应用程序文件本身携带第一授权文件信息,当应用程序文件没有被篡改时,第一授权文件信息和第二授权文件信息是一致的,第一校验码和第二校验码也是一致的,当应用程序文件被篡改后,第一授权文件信息和第二授权文件信息是不一致的,第一校验码和第二校验码也不一致,通过这种方式,能够在移动端确定应用程序文件的安全性,且不用输入较长的代码。
其中,第一授权文件信息为第一签名信息,第二授权文件信息为第二签名信息。
此时,步骤S101中,移动设备获取应用程序文件的第二校验码的步骤,可以通过两种方式实现,一种是在网络连通的情况下,移动设备可以通过网络从服务器获得第二校验码,另一种情况是,开发商将第二校验码内置在应用程序文件的正版中,当用户获得应用程序文件的正版,在自己的移动设备安装应用程序的正版后,在该应用程序(即安装的应用程序文件的正版)后续的验证中,可以不依赖网络,移动设备直接获取内置在应用程序文件中的第二校验码。
参见图2,不管是上述哪一种方式,在步骤S101之前,首先均需要生成第二校验码,结合起来具体过程可以如下:
步骤S103:服务器通过散列算法对应用程序文件的正版已设置的第二签名信息进行计算,得到第二校验码。该步骤可以在应用开发商或应用开发商授权的服务商处完成。进一步地,服务器将第二校验码内置在应用程序文件的正版中,该内置有第二校验码的应用程序文件的正版达到用户端。
如果在应用程序文件启动时有网络,移动设备通过网络获取第二校验码,则进入步骤S1011,如果在应用程序文件启动时没有网络,移动设备在本地获取第二校验码,则进入步骤S1012。
步骤S1011:通过网络连接服务器,进而从服务器获得应用程序文件的第二校验码。
步骤S1012:获取内置在应用程序文件的第二校验码。
很显然,虽然第二校验码是内置在应用程序文件的正版中,但是依然存在安全性的风险。进一步地,可以通过公、私密钥的方式对第二校验码进行加密和解密处理,以进一步增加应用程序文件的安全性。
其中,步骤S101中,移动设备获取应用程序文件的第一校验码的步骤可以是:步骤S1013,通过散列算法对应用程序文件本身携带的第一签名信息进行计算,得到第一校验码。即获得第一校验码的方法和获得第二校验码的方法都是一样的,都是散列算法。
散列算法是指产生一些数据片段(例如消息或会话项)的散列值的算法。好的散列算法具有根据输入数据中的变动来更改散列值结果的特性;因此,散列对于检测在诸如消息等大型信息对象中的任何变化很有用。
软件开发中的散列函数或散列算法,又称哈希函数(Hash Function),是一种从任何一种数据中创建小的数字“指纹”的方法。散列函数把消息或数据压缩成摘要,使得数据量变小,将数据的格式固定下来。该函数将数据打乱混合,重新创建一个叫做散列值的指纹。散列值通常用来代表一个短的随机字母和数字组成的字符串。好的散列函数在输入域中很少出现散列冲突。在散列表和数据处理中,不抑制冲突来区别数据,会使得数据库记录更难找到。所有的散列函数都有如下一个基本特性:如果两个散列值是不相同的(根据同一函数),那么这两个散列值的原始输入也是不相同的。散列算法包括但不限于SHA1、MD5、SHA256等。当然,获得第一校验码的方法和获得第二校验码的方法除了是上述的散列算法外,还可以是其它方法,在此不做限定。
在实际应用中,上述签名信息验证过程可以用Java代码实现验证,也可以用C语言代码实现验证,具体如下:
1、Java层浅校验(验证代码在Java层);
例如,Java代码中验证签名具体可以是:
由于Java代码中包括很多源代码信息,如变量名、方法名,并且通过这些名称来访问变量和方法,这些符号带有许多语义信息,很容易被反编译成Java源代码。为了防止这种现象,可以对Java代码采用代码混淆的方式,提高反编译的难度。
2、原生开发工具包(Native Development Kit,简写NDK)C代码中深校验(验证代码在NDK的C代码中);
C语言的实现与Java的实现在流程上类似,仅代码不同,不再详细举例。由于C语言写的程序一般很难反编译,不可能得到源码,编译完成后已经转化为机器语言,不是完全可逆的过程,因此反编译C语言生成的工程,比反编译Java的工程困难很多。
本发明实施例中,验证应用程序文件的过程可以在后台校验,不影响应用程序文件的启动速度。
其中,第二授权文件信息包括与应用程序文件的正版对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息;第一授权文件信息包括与应用程序文件对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息。其中,功能限定信息即限定应用程序文件可用功能的信息,所述第一授权文件信息也是与第二授权文件信息相互对应,例如,第二授权文件信息包括应用程序文件的正版对应的应用程序文件包名,那么第一授权文件信息也包括与应用程序文件对应的应用程序文件包名;又如,第二授权文件信息包括应用程序文件的正版对应的应用程序文件包名和设备序列号,那么第一授权文件信息也包括与应用程序文件对应的应用程序文件包名和设备序列号。当然,第二授权文件信息并不限于上述内容,在此并不做限定。
其中,所述与应用程序文件的正版对应的应用程序文件包名、设备序列号、设备型号等类别的授权信息中,均可以包括多个对象,即若第一授权文件信息包括与应用程序文件对应的应用程序文件包名时,该与应用程序文件的正版对应的应用程序文件包名中可以包括多个应用程序文件包名,例如e本阅读器,e本商城等;若第一授权文件信息包括设备序列号时,则该设备序列号可以包括多个设备序列号;若第一授权文件信息包括设备型号,设备型号也可以包括多个设备型号,例如E人E本T8、E人E本T9等。同理,第二授权文件信息也可以这样设置,这样可以实现一个授权文件包对多个应用程序文件,或多个设备序列号,或多个设备型号实现授权,以提高应用程序文件授权验证效率。
此时,参见图3,步骤S101中,移动设备获取应用程序文件的第一校验码和第二校验码的步骤之前,还包括:
步骤S201:服务器生成与应用程序文件的正版对应的文本格式的第二授权文件信息。
应用程序文件的正版在出厂前,根据应用程序文件包名、设备序列号、设备型号(或者设备定制型号)、设定的有效期等中的至少一个生成文本格式的第二授权文件信息,该文本格式可以是.txt格式、JSON格式、或者XML格式等,其中,优选JSON格式的授权文件信息,JSON格式的授权文件信息在后续授权项的比对中,比对效率高。
例如,第二授权文件信息authorization.json(详见下面举例说明)。
步骤S202:服务器通过散列算法对第二授权文件信息进行计算,得到授权校验码,授权校验码即为第二校验码。
例如,根据散列算法,如SHA1、MD5、或SHA256等,对第二授权文件信息求值,得到散列值即为授权校验码,如SHA1值、MD5值,或SHA256值等。
若第二授权文件信息求的授权校验码发生变化,则对应的第二授权文件信息即被修改,因此通过授权校验码可以判断第二授权文件信息是否被修改,第二授权文件信息被修改后(授权校验码发生改变),即可认为第二授权文件信息失效,该应用程序文件的正版已经被修改。
同样,步骤S101中,移动设备获取应用程序文件的第一校验码的步骤,可以是:移动设备获取授权文件包,该授权文件包中包括第二校验码的信息;通过散列算法对应用程序文件本身携带的第一授权文件信息进行计算,得到第一校验码。
所述授权文件包中包括所述第二校验码的信息,可以是第二检验码,或者,可以是所述授权文件签名(授权文件签名是加密第二检验码得到的)。
需要说明的是:当第二授权文件信息为与应用程序文件的正版对应的应用程序文件包名、设备序列号、设备型号、设定的有效期中的一个时,第一授权文件信息也是对应的一个;当第二授权文件信息为与应用程序文件的正版对应的应用程序文件包名、设备序列号、设备型号、设定的有效期中的二个时,第一授权文件信息也是对应的二个,此时还可以设定进一步的应用程序文件验证,例如:第二授权文件信息为与应用程序文件的正版对应的应用程序文件包名、设备序列号,第一授权文件信息是与应用程序文件对应的应用程序文件包名、设备序列号。在第二授权文件信息(如下描述的authorization.json)中,可以进一步说明授权项还包括设定的有效期,即当第二校验码和第一校验码一致,通过验证后,进行进一步的验证,确认应用程序文件的有效期是否在设定的有效期内,如果不在设定的有效期内,则该验证不通过。
又如:第二授权文件信息为设备序列号,第一授权文件信息是设备序列号,在第二授权文件信息中,可以进一步说明授权项还包括应用程序文件包名、设备型号、设定的有效期,即当第二校验码和第一校验码一致,通过验证后,进行进一步的验证,分别确认应用程序文件的应用程序文件包名、设备型号、有效期是否与第二授权文件信息中设定的一致,只要其中有一项不一致,则该验证不通过。
当然,上述例子中,也可以在第一次验证时,第二授权文件信息包括全部的授权项,只有在包括全部授权项的第二校验码和包括全部授权项的第一校验码一致时,才算通过验证。具体如何实现应用程序文件的验证,可以根据实际应用的需要确定,在此不做限定。
移动设备在获取第二校验码时,依然可以采用联网从服务器获取和在本地获取两种方式,在此不再赘叙。下面主要是说明在本地获取时,为了进一步保证应用程序文件的安全性所采取的措施。
参见图4,步骤S202之后,还可以包括:
步骤S203:服务器通过非对称加密算法生成公钥和私钥。
非对称加密算法,如RSA、Elgamal、背包算法、Rabin、D-H、ECC等。应用开发商保留私钥,私钥用于加密授权校验码,以生成授权文件签名(如下步骤S204),公钥用于解密授权文件签名,得到授权校验码。当然,也可以使用对称加密算法,在此不做限定。
步骤S204:服务器使用私钥对授权校验码加密,生成授权文件签名,例如:authorization.json.sign授权文件签名。
其中,第二授权文件信息、授权文件签名、公钥均需要内置于应用程序文件中。例如,将第二授权文件信息authorization.json,授权文件签名authorization.json.sign打包,生成zip压缩包(授权文件包),如授权文件包license.zip;将授权文件包license.zip发给申请授权后获得授权的用户,或者直接在设备或终端出厂前利用授权文件包license.zip对预装应用进行授权。
服务器可以将公钥内置在应用程序文件的正版中,也可以保存在服务器本地。当移动设备不联网进行验证时,服务器可以将公钥内置在应用程序文件的正版中,当移动设备联网进行验证时,服务器可以将公钥保存在服务器本地。联网或不联网进行验证的流程,可以参见上述内容,在此不再赘叙。
此时,参见图5,步骤S101中,移动设备获取应用程序文件的第二校验码的步骤,包括:
步骤S301:移动设备获取内置在应用程序文件的公钥。
步骤S302:移动设备通过公钥对授权文件签名进行解密,获得授权验证码,授权验证码即为第二校验码。
需要说明的是,上述步骤S101和步骤S102的执行可以是在应用程序文件启动的时候执行,也可以是在应用程序文件运行过程中执行。
授权文件包中还包括第二授权文件信息,第二授权文件信息、第一授权文件信息中每个类别的授权信息均对应一个授权项;移动设备在第一校验码和第二校验码一致时,确定应用程序文件通过验证,包括:
在第一校验码和第二校验码一致时,移动设备将第二授权文件信息中每个授权项分别与第一授权文件信息中对应的授权项进行比对,若第二授权文件信息中每个授权项与第一授权文件信息中对应的授权项都匹配,则确定应用程序文件通过验证。
授权项可以是应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息。对应的授权项匹配是指具体的授权项的授权内容相匹配。若第二授权文件信息中每个授权项与第一授权文件信息中对应的授权项都匹配,即表示第二授权文件信息与第一授权文件信息中相同的授权项中具有相同的目标内容,该目标内容为当前验证的应用程序文件对应的特征信息,例如应用程序文件包名,应用程序文件所在设备的设备型号(即上面所描述的设备型号),或者应用程序文件所在设备的设备序列号等。
例如,第一授权文件信息和第二授权文件信息中都包括应用程序文件包授权项,第二授权文件信息应用程序文件包授权项中包括两个应用程序文件包名,这个第一授权文件信息中应用程序文件包授权项也包括与第二授权文件信息中相同的两个应用程序文件包名,这样即表示第一授权文件信息和第二授权文件信息中的应用程序文件包授权项相匹配。
其中,在一实施方式中,该方法还包括:
服务器将一预定应用程序文件包名指定为两个以上应用程序文件的正版的通用应用程序包名;通过散列算法对预定应用程序文件包名进行计算,得到第二校验码,第二校验码为两个以上应用程序文件的正版的通用第二校验码;此时,步骤S101包括:移动设备在确定两个以上应用程序文件的本身都携带有一第一应用程序包名后,通过散列算法对第一应用程序包名进行计算,获得第一校验码,在本地或者通过网络从服务器获得第二校验码;步骤S102包括:移动设备在第一校验码和第二校验码一致时,确定两个以上应用程序文件均通过验证。
对于批量的两个以上的应用程序文件,如果按照上述方式,一个一个地来分别进行验证,验证过程比较长,且比较浪费时间,通过上述方式,能够通过一个通用第二校验码,使两个以上的批量应用程序文件均通过验证,从而简化验证过程。
其中,在一实施方式中,该方法还包括:
服务器分别将一系列多个设备序列号或设备型号指定为一应用程序文件的正版的设备序列号或设备型号;通过散列算法分别对一系列多个设备序列号或设备型号进行计算,得到对应的多个第二校验码,多个第二校验码都是应用程序文件的正版的第二校验码;此时,步骤S101包括:移动设备通过散列算法对应用程序文件本身携带的设备序列号或设备型号进行计算,获得第一校验码,在本地或者通过网络从服务器获得多个第二校验码;步骤S102包括:移动设备在确定多个第二校验码中有一个第二校验码与第一校验码一致时,确定应用程序文件通过验证。
当一个应用程序在多个一系列设备上分别进行验证时,采用上述的方法一个一个地来分别进行验证,验证过程比较长,且比较浪费时间,通过上述方式,能够在简化验证过程的情况下,使一个应用程序文件在多个一系列设备序列号或设备型号的设备上通过验证。
其中,在一实施方式中,所述第二授权文件信息包括第二唯一标识,所述第二唯一标识为与所述应用程序文件的正版对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息;所述第一授权文件信息包括第一唯一标识,所述第一唯一标识为与所述应用程序文件对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息,此时,该方法还包括:
服务器对应用程序文件的正版携带的第二唯一标识进行分类,分为主第二唯一标识和一个以上次第二唯一标识;通过散列算法,分别对主第二唯一标识和一个以上次第二唯一标识进行计算,分别得到主第二校验码和一个以上次第二校验码;此时,步骤S101包括:移动设备对应用程序文件本身携带的第一唯一标识进行对应的分类,分为对应的主第一唯一标识和一个以上次第一唯一标识;移动设备通过散列算法,分别对主第一唯一标识和一个以上次第一唯一标识进行计算,获得主第一校验码和一个以上次第一校验码;移动设备在本地或者通过网络从服务器获得主第二校验码和一个以上次第二校验码;步骤S102包括:移动设备在主第一校验码和主第二校验码一致时,确定应用程序文件通过第一级验证;移动设备再分别逐级比较一个以上次第一校验码和一个以上次第二检验码,当一个以上次第一校验码和一个以上次第二检验码分别逐级一致时,确定应用程序文件分别通过逐级验证。
上述方式是另一种实现分级验证的方式,即一级一级比较各项授权项,在各个授权项均通过验证的情况下,最后确定应用程序文件通过验证。因此,通过上述方式,能够实现逐级验证。
下面以E本阅读器的JSON格式第二授权文件信息为例进行说明,E本阅读器的应用程序文件包名“cn.eben.reader”
上述以[]标示的应用包名、设备序列号、设备型号、设备定制型号等,可以包括多个值。
此授权文件信息中包括多个授权项,例如应用程序文件包名、设备序列号、设备型号、功能限定信息等,每个授权项也可以对多个对象的限定。例如:当第二授权文件信息包括应用程序文件包名时,应用程序文件包名对应的授权项中可以包括多个应用程序文件包名,例如e本阅读器,e本商城等,又例如,当第二授权文件信息包括设备型号时,设备型号授权项中可以包括一个设备的一个或多个设备型号,例如设备型号包括E人E本T8、E人E本T9,那么该授权文件信息对E人E本T8、E人E本T9的设备有效。又如,即当第二授权文件信息包括设备序列号(或设备编号)时,例如可以设置E本生产时的设备编号,即知道哪些设备编号是e本公司生产的,则可以设定这些编号可以授权使用e本阅读器。[]中的内容以“,”分隔。
上面授权文件信息的功能限定信息(extra)授权项中,可以设定哪些功能可以用,哪些功能不可用,不同的功能对应不同的授权。一般情况下,可以分为标准版(基本功能)、增强版、全功能版,每个版本可以预先设定授权不同的功能限定信息。
一个具体的JSON格式授权文件信息如下:
具体来说,在本发明一个具体实施方式中,第二授权文件信息与授权文件签名两项内容组成一个完成的授权信息,检查授权信息是否有效的过程具体可以如下:
(1)公钥内置于软件开发工具包(Software Development Kit,简写SDK),编译至应用程序文件中,应用程序文件启动后,解压该授权信息license.zip得到第二授权文件信息authorization.json和授权文件签名authorization.json.sign;
(2)用公钥解密应用程序文件的授权文件签名authorization.json.sign,得到第二授权文件信息authorization.json对应的授权校验码(如SHA1),即为第二校验码;
(3)计算解压得到的第二授权文件信息(也即是应用程序文件本身携带的第一授权文件信息)authorization.json的校验码,即为第一校验码(与第二校验码采用相同的散列算法);
(4)将计算出的第一校验码与解密得到的第二校验码两者进行比对,用来校验应用程序文件的第二授权文件信息authorization.json是否改动,计算出的第一校验码与解密得到的第二校验码相同,则第二授权文件信息authorization.json无改动,若第二授权文件信息authorization.json被修改,则第一校验码和第二校验码一定不相同,此授权即为无效授权;
(5)在第二授权文件信息authorization.json为有效授权文件的情况下,对第一、第二授权文件信息中其它的授权项进行进一步的检查。
在检查第一、第二授权文件信息时,每个授权文件信息中包括多个其它的授权项,在第二授权文件信息authorization.json通过第二校验码的验证,初步确认有效的授权文件信息的情况下,需要再进一步一一校验第一、第二授权文件信息中其它授权项,第一、第二授权文件信息中所有的其它授权项都为可选项,所有项共同生效才能保证授权文件信息实质有效,即authorization.json中的授权项,需要一一校验,若全部通过,则该应用文件程序通过验证,授权有效,每一授权项的无效都能否定应用程序文件的有效性。通过上述方式,可以实现分级验证。
参见图6,本发明还提供一种应用程序文件验证的***,该***可以执行上述方法中的步骤,相关的详细内容请参见上述方法部分,在此不再赘叙。
该***10包括:移动设备100,该移动设备100包括:获取模块101和确定模块102。
获取模块101用于获取应用程序文件的第一校验码和第二校验码,其中,第一校验码是根据应用程序文件本身携带的第一授权文件信息得到的,第二校验码是根据应用程序文件的正版携带的第二授权文件信息得到的。
确定模块102用于在第一校验码和第二校验码一致时,确定应用程序文件通过验证。
本发明实施方式移动设备获取应用程序文件的第一校验码和第二校验码,第一校验码是根据所述应用程序文件本身携带的第一授权文件信息得到的,所述第二校验码是根据所述应用程序文件的正版携带的第二授权文件信息得到的;所述移动设备在所述第一校验码和所述第二校验码一致时,确定所述应用程序文件通过验证。由于应用程序文件的正版携带的第二授权文件信息,应用程序文件本身携带第一授权文件信息,当应用程序文件没有被篡改时,第一授权文件信息和第二授权文件信息是一致的,第一校验码和第二校验码也是一致的,当应用程序文件被篡改后,第一授权文件信息和第二授权文件信息是不一致的,第一校验码和第二校验码也不一致,通过这种方式,能够在移动端确定应用程序文件的安全性,且不用输入较长的代码。
其中,第一授权文件信息为第一签名信息,第二授权文件信息为第二签名信息。
其中,获取模块101具体用于在应用程序文件启动时,通过网络连接服务器,进而从服务器获得应用程序文件的第二校验码;或,在应用程序文件启动时,获取内置在应用程序文件的第二校验码。
其中,参见图7,***10还包括服务器200,服务器200包括:第一计算模块201。
第一计算模块201用于通过散列算法对应用程序文件的正版已设置的第二签名信息进行计算,得到第二校验码。
移动设备100的获取模块101具体用于通过散列算法对应用程序文件本身携带的第一签名信息进行计算,得到第一校验码。
其中,第二授权文件信息为与应用程序文件的正版对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息;第一授权文件信息为与应用程序文件对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息。
参见图8,***10还包括服务器200,服务器200包括:第一生成模块202和第二计算模块203。
第一生成模块202用于生成与应用程序文件的正版对应的文本格式的第二授权文件信息。
第二计算模块203用于通过散列算法对第二授权文件信息进行计算,得到授权校验码,授权校验码即为第二校验码。
移动设备100的获取模块101具体用于获取授权文件包,授权文件包中包括第二校验码的信息;通过散列算法对应用程序文件本身携带的第一授权文件信息进行计算,得到第一校验码。
其中,参见图9,服务器200还包括:第二生成模块204和第三生成模块205。
第二生成模块204用于通过非对称加密算法生成公钥和私钥。
第三生成模块205用于使用私钥对授权校验码加密,生成授权文件签名。
此时,移动设备100还用于:
获取内置在应用程序文件的公钥。
通过公钥对授权文件签名进行解密,获得授权验证码,授权验证码即为第二校验码。
其中,授权文件包中还包括第二授权文件信息,第二授权文件信息、第一授权文件信息中每个类别的授权信息均对应一个授权项;确定模块还用于在第一校验码和第二校验码一致时,将第二授权文件信息中每个授权项分别与第一授权文件信息中对应的授权项进行比对,若第二授权文件信息中每个授权项与第一授权文件信息中对应的授权项都匹配,则确定应用程序文件通过验证。
以上所述仅为本发明的实施方式,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。
Claims (12)
1.一种应用程序文件验证的方法,其特征在于,所述方法包括:
移动设备获取应用程序文件的第一校验码和第二校验码,其中,所述第一校验码是根据所述应用程序文件本身携带的第一授权文件信息得到的,所述第二校验码是根据所述应用程序文件的正版携带的第二授权文件信息得到的;
所述移动设备在所述第一校验码和所述第二校验码一致时,确定所述应用程序文件通过验证。
2.根据权利要求1所述的方法,其特征在于,所述第一授权文件信息为第一签名信息,所述第二授权文件信息为第二签名信息;
所述移动设备获取所述应用程序文件的第一校验码和第二校验码的步骤之前,还包括:
服务器通过散列算法对所述应用程序文件的正版已设置的所述第二签名信息进行计算,得到所述第二校验码;
所述移动设备获取所述应用程序文件的第一校验码和第二校验码的步骤,包括:
所述移动设备在所述应用程序文件启动时,通过网络连接服务器,进而从所述服务器获得所述应用程序文件的第二校验码,或,所述移动设备在所述应用程序文件启动时,获取内置在所述应用程序文件的所述第二校验码;
所述移动设备通过所述散列算法对所述应用程序文件本身携带的所述第一签名信息进行计算,得到所述第一校验码。
3.根据权利要求1所述的方法,其特征在于,所述第二授权文件信息包括与所述应用程序文件的正版对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息;所述第一授权文件信息包括与所述应用程序文件对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息。
4.根据权利要求3所述的方法,其特征在于,所述移动设备获取应用程序文件的第一校验码和第二校验码的步骤之前,还包括:
服务器生成与所述应用程序文件的正版对应的文本格式的所述第二授权文件信息;
所述服务器通过散列算法对所述第二授权文件信息进行计算,得到授权校验码,所述授权校验码即为所述第二校验码;
所述移动设备获取应用程序文件的第一校验码和第二校验码的步骤,包括:
所述移动设备获取授权文件包,所述授权文件包中包括所述第二校验码的信息;
所述移动设备通过所述散列算法对所述应用程序文件本身携带的所述第一授权文件信息进行计算,得到所述第一校验码。
5.根据权利要求4所述的方法,其特征在于,
所述服务器通过散列算法对所述第二授权文件信息进行计算,得到授权校验码的步骤之后,还包括:
所述服务器通过非对称加密算法生成公钥和私钥;
所述服务器使用所述私钥对所述授权校验码加密,生成授权文件签名;
所述第二校验码的信息为所述授权文件签名,所述移动设备获取应用程序文件的第一校验码和第二校验码的步骤,还包括:
所述移动设备获取内置在所述应用程序文件的所述公钥;
所述移动设备通过所述公钥对所述授权文件签名进行解密,获得所述授权验证码,所述授权验证码即为所述第二校验码。
6.根据权利要求5所述的方法,其特征在于,所述授权文件包中还包括所述第二授权文件信息,所述第二授权文件信息、所述第一授权文件信息中每个类别的授权信息均对应一个授权项;
所述移动设备在所述第一校验码和所述第二校验码一致时,确定所述应用程序文件通过验证,包括:
在所述第一校验码和所述第二校验码一致时,所述移动设备将所述第二授权文件信息中每个授权项分别与所述第一授权文件信息中对应的授权项进行比对,若所述第二授权文件信息中每个授权项与所述第一授权文件信息中对应的授权项都匹配,则确定所述应用程序文件通过验证。
7.一种应用程序文件验证的***,其特征在于,所述***包括:移动设备,所述移动设备包括:
获取模块,用于获取应用程序文件的第一校验码和第二校验码,其中,所述第一校验码是根据所述应用程序文件本身携带的第一授权文件信息得到的,所述第二校验码是根据所述应用程序文件的正版携带的第二授权文件信息得到的;
确定模块,用于在所述第一校验码和所述第二校验码一致时,确定所述应用程序文件通过验证。
8.根据权利要求7所述的***,其特征在于,所述第一授权文件信息为第一签名信息,所述第二授权文件信息为第二签名信息;
所述***还包括:服务器,所述服务器包括:
第一计算模块,用于通过散列算法对所述应用程序文件的正版已设置的所述第二签名信息进行计算,得到所述第二校验码;
所述获取模块具体用于:
在所述应用程序文件启动时,通过网络连接服务器,进而从所述服务器获得所述应用程序文件的第二校验码,或,在所述应用程序文件启动时,获取内置在所述应用程序文件的所述第二校验码;
通过所述散列算法对所述应用程序文件本身携带的所述第一签名信息进行计算,得到所述第一校验码。
9.根据权利要求7所述的***,其特征在于,所述第二授权文件信息包括与所述应用程序文件的正版对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息;所述第一授权文件信息包括与所述应用程序文件对应的应用程序文件包名、设备序列号、设备型号、设定的有效期、功能限定信息中的至少一个类别的授权信息。
10.根据权利要求9所述的***,其特征在于,所述***还包括:服务器,所述服务器包括:
第一生成模块,用于生成与所述应用程序文件的正版对应的文本格式的所述第二授权文件信息;
第二计算模块,用于通过散列算法对所述第二授权文件信息进行计算,得到授权校验码,所述授权校验码即为所述第二校验码;
所述获取模块具体用于:
获取授权文件包,所述授权文件包中包括所述第二校验码的信息;
通过所述散列算法对所述应用程序文件本身携带的所述第一授权文件信息进行计算,得到所述第一校验码。
11.根据权利要求10所述的***,其特征在于,
所述服务器还包括:
第二生成模块,用于通过非对称加密算法生成公钥和私钥;
第三生成模块,用于使用所述私钥对所述授权校验码加密,生成授权文件签名;
所述第二校验码的信息为所述授权文件签名,所述获取模块还用于:
获取内置在所述应用程序文件的所述公钥;
通过所述公钥对所述授权文件签名进行解密,获得所述授权验证码,所述授权验证码即为所述第二校验码。
12.根据权利要求11所述的***,其特征在于,所述授权文件包中还包括所述第二授权文件信息,所述第二授权文件信息、所述第一授权文件信息中每个类别的授权信息均对应一个授权项;
所述确定模块还用于在所述第一校验码和所述第二校验码一致时,将所述第二授权文件信息中每个授权项分别与所述第一授权文件信息中对应的授权项进行比对,若所述第二授权文件信息中每个授权项与所述第一授权文件信息中对应的授权项都匹配,则确定所述应用程序文件通过验证。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610395335.7A CN106096381A (zh) | 2016-06-06 | 2016-06-06 | 应用程序文件验证的方法及*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610395335.7A CN106096381A (zh) | 2016-06-06 | 2016-06-06 | 应用程序文件验证的方法及*** |
Publications (1)
Publication Number | Publication Date |
---|---|
CN106096381A true CN106096381A (zh) | 2016-11-09 |
Family
ID=57447842
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610395335.7A Pending CN106096381A (zh) | 2016-06-06 | 2016-06-06 | 应用程序文件验证的方法及*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN106096381A (zh) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108008976A (zh) * | 2017-12-27 | 2018-05-08 | 上海贝岭股份有限公司 | 软件标识生成方法、计算机可读存储介质及单片机 |
CN108092947A (zh) * | 2016-11-23 | 2018-05-29 | 腾讯科技(深圳)有限公司 | 一种对第三方应用进行身份鉴别的方法及装置 |
CN108268767A (zh) * | 2016-12-30 | 2018-07-10 | 北京国双科技有限公司 | Web应用程序授权方法及装置 |
CN108549826A (zh) * | 2018-03-30 | 2018-09-18 | 努比亚技术有限公司 | 应用程序的校验方法、终端、服务器及可读存储介质 |
CN110289947A (zh) * | 2019-04-29 | 2019-09-27 | 北京开态智慧科技有限公司 | 数据传输一致性校验方法、装置、计算机设备及存储介质 |
CN110348235A (zh) * | 2019-07-17 | 2019-10-18 | 政采云有限公司 | 一种文件检测方法及装置 |
CN110609789A (zh) * | 2019-08-29 | 2019-12-24 | 烽火通信科技股份有限公司 | 一种用于软件License校验的方法和*** |
CN110795103A (zh) * | 2019-09-27 | 2020-02-14 | 北京五八信息技术有限公司 | 一种代码编译方法以及编译机 |
CN111767537A (zh) * | 2020-06-23 | 2020-10-13 | 平安普惠企业管理有限公司 | 基于ios操作***的应用程序的篡改校验方法及相关设备 |
CN114676393A (zh) * | 2022-05-26 | 2022-06-28 | 杭州微帧信息科技有限公司 | 一种软件离线鉴权方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040147251A1 (en) * | 2002-11-21 | 2004-07-29 | Ntt Docomo, Inc. | Communication terminal, value entity providing server, application delivery server, electronic procurement supporting method, and electronic procurement supporting program |
CN102314578A (zh) * | 2011-09-26 | 2012-01-11 | 浪潮(北京)电子信息产业有限公司 | 一种实现软件保护的***及方法 |
CN104426658A (zh) * | 2013-09-02 | 2015-03-18 | ***通信集团公司 | 对移动终端上的应用进行身份验证的方法及装置 |
-
2016
- 2016-06-06 CN CN201610395335.7A patent/CN106096381A/zh active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040147251A1 (en) * | 2002-11-21 | 2004-07-29 | Ntt Docomo, Inc. | Communication terminal, value entity providing server, application delivery server, electronic procurement supporting method, and electronic procurement supporting program |
CN102314578A (zh) * | 2011-09-26 | 2012-01-11 | 浪潮(北京)电子信息产业有限公司 | 一种实现软件保护的***及方法 |
CN104426658A (zh) * | 2013-09-02 | 2015-03-18 | ***通信集团公司 | 对移动终端上的应用进行身份验证的方法及装置 |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108092947A (zh) * | 2016-11-23 | 2018-05-29 | 腾讯科技(深圳)有限公司 | 一种对第三方应用进行身份鉴别的方法及装置 |
CN108092947B (zh) * | 2016-11-23 | 2020-12-04 | 腾讯科技(深圳)有限公司 | 一种对第三方应用进行身份鉴别的方法及装置 |
CN108268767A (zh) * | 2016-12-30 | 2018-07-10 | 北京国双科技有限公司 | Web应用程序授权方法及装置 |
CN108008976A (zh) * | 2017-12-27 | 2018-05-08 | 上海贝岭股份有限公司 | 软件标识生成方法、计算机可读存储介质及单片机 |
CN108549826A (zh) * | 2018-03-30 | 2018-09-18 | 努比亚技术有限公司 | 应用程序的校验方法、终端、服务器及可读存储介质 |
CN110289947A (zh) * | 2019-04-29 | 2019-09-27 | 北京开态智慧科技有限公司 | 数据传输一致性校验方法、装置、计算机设备及存储介质 |
CN110348235A (zh) * | 2019-07-17 | 2019-10-18 | 政采云有限公司 | 一种文件检测方法及装置 |
CN110609789A (zh) * | 2019-08-29 | 2019-12-24 | 烽火通信科技股份有限公司 | 一种用于软件License校验的方法和*** |
CN110795103A (zh) * | 2019-09-27 | 2020-02-14 | 北京五八信息技术有限公司 | 一种代码编译方法以及编译机 |
CN111767537A (zh) * | 2020-06-23 | 2020-10-13 | 平安普惠企业管理有限公司 | 基于ios操作***的应用程序的篡改校验方法及相关设备 |
CN114676393A (zh) * | 2022-05-26 | 2022-06-28 | 杭州微帧信息科技有限公司 | 一种软件离线鉴权方法 |
CN114676393B (zh) * | 2022-05-26 | 2022-08-26 | 杭州微帧信息科技有限公司 | 一种软件离线鉴权方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106096381A (zh) | 应用程序文件验证的方法及*** | |
CN111708991B (zh) | 服务的授权方法、装置、计算机设备和存储介质 | |
JP4113274B2 (ja) | 認証装置および方法 | |
CN103167491B (zh) | 一种基于软件数字证书的移动终端唯一性认证方法 | |
WO2015101336A1 (en) | Signature verification method, apparatus, and system | |
CN106991298A (zh) | 应用程序对接口的访问方法、授权请求方法及装置 | |
US20140157368A1 (en) | Software authentication | |
CN113709115B (zh) | 认证方法及装置 | |
CN108075888A (zh) | 动态url生成方法及装置 | |
CN114444134A (zh) | 一种数据使用授权方法、***及装置 | |
CN113032837A (zh) | 开放平台匿名鉴权方法及*** | |
Zhang | A study on application of digital signature technology | |
CN111241492A (zh) | 一种产品多租户安全授信方法、***及电子设备 | |
KR100912532B1 (ko) | 신뢰 컴퓨팅 환경에서 각 참여자가 상호 보증 기능을 갖는인터넷 전자투표 방법 및 시스템 | |
CN114826572A (zh) | 支持属性隐私保护的去中心化众包方法、***及终端 | |
CN112380501B (zh) | 设备运行方法、装置、设备和存储介质 | |
KR20140061788A (ko) | 무결성이 보장되는 프로그램 코드를 이용한 보안 방법 및 서버 | |
CN112039675A (zh) | 一种基于区块链智能合约的令牌生成与认证方法 | |
Sevis et al. | Survey on data integrity in cloud | |
CS Machado et al. | Software control and intellectual property protection in cyber-physical systems | |
CN115550060B (zh) | 基于区块链的可信证书验证方法、装置、设备和介质 | |
CN104994503B (zh) | 一种移动应用访问方法 | |
CN114125158B (zh) | 基于可信电话的防骚扰方法、装置、设备及存储介质 | |
CN114698408B (zh) | 多接收方安全通信 | |
CN110351090B (zh) | 群签名数字证书吊销方法及装置、存储介质、电子设备 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20161109 |