一种对应用程序进行安全认证的方法和装置与流程

文档序号:18133782发布日期:2019-07-10 10:27阅读:238来源:国知局
一种对应用程序进行安全认证的方法和装置与流程

本发明涉及计算机技术领域,尤其涉及一种对应用程序进行安全认证的方法和装置。



背景技术:

从ios8系统(iphoneoperatingsystem,苹果公司开发的移动操作系统)开始,操作系统才允许带有动态库的app(application,应用程序)通过审核。随着app业务的发展,app的体量会越来越大。app继续支持到ios7就会面临一个限制:苹果对于ios7框架下的可执行文件大小限制在60m以内。因此,需要将一部分业务转成动态库,即将app的一部分可执行文件转到动态库中去。

在实现本发明过程中,发明人发现现有技术中至少存在如下问题:由于动态库放在资源中是很容易被获取到的(例如,通过对ipa安装包解压),而且动态库是可以独立引用的,因此运行在ios越狱设备上的app面临着堵多安全隐患。比如,app的主库容易被hook(挂钩)或者注入、被改变boundid(app唯一标识)后重新签名打包,app的动态库容易被取出引用或者被替换。



技术实现要素:

有鉴于此,本发明实施例提供一种对应用程序进行安全认证的方法和装置,能够解决app面临着堵多安全隐患的问题。

为实现上述目的,根据本发明实施例的一个方面,提供了一种对应用程序进行安全认证的方法,包括:

获取主库的动态属性数据,对所述动态属性数据进行签名,生成第一动态签名;

获取存储在动态库中的所述主库的静态属性数据,对所述静态属性数据进行签名,生成第一静态签名;

比较所述第一动态签名和第一静态签名是否一致,以完成对主库的安全认证。

可选地,所述方法还包括:

获取动态库的动态属性数据,对所述动态属性数据进行签名,生成第二动态签名;

获取存储在主库中的所述动态库的静态属性数据,对所述静态属性数据进行签名,生成第二静态签名;

比较所述第二动态签名和第二静态签名是否一致,以完成对动态库的安全认证。

可选地,所述动态属性数据包括属性的动态值,所述静态属性数据包括属性的静态值;

其中,所述属性包括应用程序的唯一标识、应用程序安装包的名字、应用程序安装后显示的名字、主库的名字、动态库的名字、被调试标识、被注入或挂钩标识、越狱标识和资源标识中的至少一种。

可选地,分别获取各个属性的动态值,然后将各个属性的动态值按照预设的顺序拼接成字符串,再所述字符串进行加密处理,生成动态签名;分别获取各个属性的静态值,然后将各个属性的静态值按照预设的顺序拼接成字符串,再所述字符串进行加密处理,生成静态签名;其中,生成所述动态签名和静态签名过程中的拼接顺序相同。

可选地,采用不可逆加密算法对按照预设顺序拼接而成的字符串进行签名。

可选地,所述方法还包括:

对所述主库的静态属性数据进行加密,以密文的形式存储在动态库中;和/或,

对所述动态库的静态属性数据进行加密,以密文的形式存储在主库中;

相应地,

所述获取存储在动态库中的所述主库的静态属性数据,包括:

获取存储在动态库中的所述静态属性数据的密文,对所述密文进行解密,得到所述主库的静态属性数据的明文;和/或,

所述获取存储在主库中的所述动态库的静态属性数据,包括:

获取存储在主库中的所述静态属性数据的密文,对所述密文进行解密,得到所述动态库的静态属性数据的明文。

另外,根据本发明实施例的另一个方面,提供了一种对应用程序进行安全认证的装置,包括:

第一签名模块,用于获取主库的动态属性数据,对所述动态属性数据进行签名,生成第一动态签名;

第二签名模块,用于获取存储在动态库中的所述主库的静态属性数据,对所述静态属性数据进行签名,生成第一静态签名;

第一对比模块,用于比较所述第一动态签名和第一静态签名是否一致,以完成对主库的安全认证。

可选地,所述装置还包括:

第三签名模块,用于获取动态库的动态属性数据,对所述动态属性数据进行签名,生成第二动态签名;

第四签名模块,用于获取存储在主库中的所述动态库的静态属性数据,对所述静态属性数据进行签名,生成第二静态签名;

第二对比模块,用于比较所述第二动态签名和第二静态签名是否一致,以完成对动态库的安全认证。

可选地,所述动态属性数据包括属性的动态值,所述静态属性数据包括属性的静态值;

其中,所述属性包括应用程序的唯一标识、应用程序安装包的名字、应用程序安装后显示的名字、主库的名字、动态库的名字、被调试标识、被注入或挂钩标识、越狱标识和资源标识中的至少一种。

可选地,所述第一签名模块、第三签名模块,分别获取各个属性的动态值,然后将各个属性的动态值按照预设的顺序拼接成字符串,再所述字符串进行加密处理,生成动态签名;

所述第二签名模块、第四签名模块,分别获取各个属性的静态值,然后将各个属性的静态值按照预设的顺序拼接成字符串,再所述字符串进行加密处理,生成静态签名;

其中,生成所述动态签名和静态签名过程中的拼接顺序相同。

可选地,采用不可逆加密算法对按照预设顺序拼接而成的字符串进行签名。

可选地,所述装置还包括:

第一加密模块,用于对所述主库的静态属性数据进行加密,以密文的形式存储在动态库中;和/或,

第二加密模块,用于对所述动态库的静态属性数据进行加密,以密文的形式存储在主库中;

相应地,

所述第二签名模块,用于获取存储在动态库中的所述静态属性数据的密文,对所述密文进行解密,得到所述主库的静态属性数据的明文;和/或,

所述第四签名模块用于,获取存储在主库中的所述静态属性数据的密文,对所述密文进行解密,得到所述动态库的静态属性数据的明文。

根据本发明实施例的另一个方面,还提供了一种电子设备,包括:

一个或多个处理器;

存储装置,用于存储一个或多个程序,

当所述一个或多个程序被所述一个或多个处理器执行,使得所述一个或多个处理器实现上述任一实施例所述的方法。

根据本发明实施例的另一个方面,还提供了一种计算机可读介质,其上存储有计算机程序,所述程序被处理器执行时实现上述任一实施例所述的方法。

上述发明中的一个实施例具有如下优点或有益效果:因为采用比较主库对应的动态签名和静态签名是否一致的技术手段,所以克服了app面临着堵多安全隐患的技术问题,本发明是通过比较主库对应的动态签名和静态签名是否一致,来验证主库是否安全,从而保证app的安全。进一步地,本发明是通过比较动态库对应的动态签名和静态签名是否一致,来验证动态库是否安全,实现主库和动态库双向认证,提高了app的安全性。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明,不构成对本发明的不当限定。其中:

图1是根据本发明实施例的对应用程序进行安全认证的方法的主要流程的示意图;

图2是根据本发明一个可参考实施例的对应用程序进行安全认证的方法的主要流程的示意图;

图3是根据本发明实施例的对应用程序进行安全认证的装置的主要模块的示意图;

图4是本发明实施例可以应用于其中的示例性系统架构图;

图5是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明,其中包括本发明实施例的各种细节以助于理解,应当将它们认为仅仅是示范性的。因此,本领域普通技术人员应当认识到,可以对这里描述的实施例做出各种改变和修改,而不会背离本发明的范围和精神。同样,为了清楚和简明,以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明实施例的对应用程序进行安全认证的方法的主要流程的示意图。作为本发明的一个实施例。该方法的执行主体可以为各类终端,如手机、平板电脑、个人电脑、个人数字助理、可穿戴设备等。如图1所示,所述对应用程序进行安全认证的方法可以包括:

步骤101,获取主库的动态属性数据,对所述动态属性数据进行签名,生成第一动态签名。

需要说明的是,应用程序安装包的解压文件中一般包括资源文件、配置文件、主库和动态库,其中,主库是指应用程序中主要的可执行文件,动态库(又称动态链接库)是指应用程序中自定义动态类型的文件和除了主库可执行文件以外的一部分可执行文件。

安卓系统中应用程序的安装包是后缀名为apk的文件,ios中应用程序的安装包是后缀名为ipa的文件。以ipa安装包为例,包含资源文件和主库执行文件,在资源文件中有一个目录中存放着动态库,动态库作为一个目录,存放着动态库执行文件和动态库资源文件(图片,文本文件等)。

可选地,所述动态属性数据包括属性的动态值,其中,所述属性包括应用程序的属性和/或自定义的属性。可选地,所述应用程序的属性可以包括应用程序的唯一标识、应用程序安装包的名字、应用程序安装后显示的名字、主库的名字和动态库的名字中的至少一种,所述自定义的属性可以包括被调试标识、被注入或挂钩标识、越狱标识和资源标识中的至少一种。

以下对这些属性和对应的作用进行说明:

(1)boundid:app的唯一标识符,每个不同的app,该值是不同的。将该值加入动态属性数据,继而生成签名,可以防止app分身版本的出现。

(2)bundlename:app安装包的名字,每个不同的app安装包,该值是不同的。将该属性的动态值加入动态属性数据,继而生成签名,也可以一定程度上防止app分身版本的出现。

(3)bundledisplayname:app安装后显示的名字,每个不同的app安装后显示的名字不同。将该属性的动态值加入动态属性数据,继而生成签名,可以禁止app的名字被修改。

(4)主库的名字:主库可执行文件的名字。可以通过获取运行在主库可执行文件类的信息,得到主库的名字。将该属性的动态值加入动态属性数据,继而生成签名,可以防止主库被转换成为动态链接库。

(5)被调试标识:通过获取系统的调试状态值,判断app是否正在被调试。如果app正在被调试,那么会返回一个调试标识(比如debuging),如果app没有被调试,那么会返回一个正常标识(比如normal)。将该属性的动态值加入动态属性数据,继而生成签名,可以防止app被调试,从而获取到app运行时候的一些动态信息(例如类信息,方法运行结果,业务运行逻辑等)。

(6)被注入或者挂钩标识:通过获取主库中n个敏感类的信息,判断它们所在的可执行文件与主库的可执行文件是否一致,如果不一致,再去判断它们所在的可执行文件与动态库的可执行文件是否相同,如果都不相同,那么则认为该敏感类被挂钩(hook)或者app被注入,就会返回被注入或者挂钩标识(比如hook);其他情况,则返回正常标识(比如normal_hook)。将该属性的动态值加入动态属性数据,继而生成签名,可以进一步保护app不被注入或者挂钩。

(7)越狱标识:根据沙盒有效性和是否存在系统被越狱的基础app,来判断操作系统是否被越狱。如果操作系统被越狱,返回越狱标识(jailbreak),如果操作系统没有被越狱,返回正常标识(比如no_jaibreak)。将该属性的动态值加入动态属性数据,继而生成签名,可以保证app在正常渠道下载运行,进而保证app的安全。

针对苹果公司开发的移动操作系统,ios越狱(iosjailbreaking)是用于获取ios操作系统最高权限的一种技术手段,用户使用这种技术手段可以获取到ios操作系统的最高权限。

(8)资源标识:随机认定几个主库资源文件。通过判断主库资源文件是否都存在,来返回标识。如果都存在返回正常标识(resource);如果某些不存在,那么返回异常标识(resource_failure)。将该属性的动态值加入动态属性数据,继而生成签名,可以将主库的资源文件和主库的可执行文件进行绑定,进一步保证app的安全。

需要说明的是,预先认定与主库的可执行文件绑定的资源文件,认定的数量不限,数量越多,越有利于保证app的安全。

由于操作系统将对象的属性和属性值拆分成key和value,因此通过字符串key来获取该属性的值。具体地,将加密后的字符串key值进行解密,得到明文的key值,采用明文的key值读取app的属性值。

app在安装后,app的各个属性值还有可能被改变,那么动态获取到的属性值可能就会改变。由于主库与动态库是互相独立的,通过判定主库对应的这些属性的动态值,来判断主库是否安全,从而达到保护app的作用。可选地,关于app安全校验的属性值都可以加入到动态属性数据中,不限于本发明所述的属性,从而达到从不同角度确保app安全的目的。

作为本发明的又一个实施例,步骤101包括:分别获取主库对应的各个属性的动态值,然后将各个属性的动态值按照预设的顺序拼接成字符串,再所述字符串进行签名,生成第一动态签名。

可选地,采用不可逆加密算法对所述字符串进行签名。因为签名是不可逆的,所以能够有效地保证原数据的安全。例如,md5全名message-digestalgorithm5(信息-摘要算法),是一种不可逆的加密算法,其具有以下优点:1、压缩性:任意长度的数据,算出的md5值长度都是固定的;2、容易计算:从原数据计算出md5值很容易;3、抗修改性:对原数据进行任何改动,哪怕只修改1个字节,所得到的md5值都有很大区别;4、强抗碰撞:已知原数据和其md5值,想找到一个具有相同md5值的数据(即伪造数据)是非常困难的。

具体地,可以通过代码调用的方式,分别获取主库对应的各个属性的动态值。根据获得的动态值,按照预设的顺序拼接成一个字符串,然后对该字符串进行md5处理,处理的结果即为第一动态签名。

作为本发明的一个实施例,可以由动态库向主库发起请求,以获得第一动态签名。具体地,动态库通过n个字符串拼接成一个类名字符串,然后通过发射机制,转成类的名字,再调用主库中对应类的方法,从而获取到返回值(即第一动态签名),从而完成动态库和主库的通信过程。需要指出的是,在获取签名的过程中,并不带有其他的信息。可选地,请求动态起签名的操作可以发生在主库的c语言构造函数里面,c语言构造函数是在app启动后自动调用的,这样可以尽早地使本发明实施例提供的方法发挥作用,从而尽早地保证app的安全。因此,在该实施例中,通过拼接字符串,然后反射类,实现主库与动态库之间的通信。主库和动态库都在一个app中,运行时候,是主库加载动态库进行执行。因为这些特性的存在,才能保证这种特殊通信方式的可行。而且,动态库与主库之间的传值,仅仅是传签名值,不带有任何其他的信息。

作为本发明的又一个实施例,也可以由独立的管理程序向主库发起请求,以获得第一动态签名,也能够达到与上述方案相同或者相似的技术效果。

在本发明中,传递的值可以仅仅是签名值,不带有任何其他的信息,通过签名值是否正确来认证主库是否安全,所以不需要保证其他通信数据的安全,这较大地提高了认证效率和认证可靠性。

步骤102,获取存储在动态库中的所述主库的静态属性数据,对所述静态属性数据进行签名,生成第一静态签名。

在该步骤中,分别获取主库对应的各个属性的静态值,然后将各个属性的静态值按照预设的顺序拼接成字符串,再所述字符串进行加密处理,生成第一静态签名。可以预先将所述静态值存储在动态库中。可选地,所述静态属性数据包括属性的静态值,其中,所述属性包括应用程序的属性和/或自定义的属性。

需要指出的是,在步骤102中,拼接字符串所采用的属性与步骤101中所采用的属性相同,不同的是,步骤102中所采用的是属性的静态值,而步骤101中所采用的是属性的动态值。而且,在步骤102中,拼接字符串的顺序与步骤101中拼接字符串的顺序相同。

所述字符串的拼接顺序可以预先设定,获取的属性也可以预先设定,从而使步骤101和步骤102均按照相同的属性获取属性值,并按照相同的顺序拼接这些属性值。因此,也需要采用相同的方法对字符串进行加密处理,例如采用md5对字符串进行加密处理,处理的结果即为第一静态签名,以使第一动态签名与第一静态签名具有可比较性。

以应用程序的属性(例如boundid、boundname、bounddisplayname、主库的名字和动态库的名字)为例,其静态值为未被修改的app属性值。以自定义的属性为例,其静态值为未被调试标识(比如normal)、未被注入或挂钩标识(比如normal_hook)、未越狱标识(比如no_jaibreak)和资源标识(比如resource)中的至少一种。

需要指出的是,可以先执行步骤101,再执行步骤102;也可以先执行步骤102,再执行步骤101;还可以同时执行步骤101、步骤102。图1仅仅是示例性地示出了先执行步骤101、再执行步骤102的流程图,本发明不限于该流程图。

步骤103,比较所述第一动态签名和第一静态签名是否一致,以完成对主库的安全认证。

静态签名的目的是对动态签名的值进行验证,静态签名能够验证动态签名的值是否正常。如果第一动态签名和第一静态签名的值不一致,说明主库不再安全。如果第一动态签名和第一静态签名的值一致,说明主库仍然是安全的。

在该步骤中,比较第一动态签名和第一静态签名的值是否一致。如果不一致,则对比较的结果做异常处理(例如退出app、抛出异常、上报服务端等等);如果一致,则结束,从而完成对主库的安全认证。这样就阻止了破坏app行为的继续执行,可见,本发明实施例提供的方法可以比较全面地保证app的安全。

根据上面所述的各种实施例,可以看出本发明通过采用比较主库对应的动态签名和静态签名是否一致的技术手段,从而解决了app面临着堵多安全隐患的问题。也就是说,在现有技术中,app的主库容易被hook或者注入、被改变app属性值,导致app面临着堵多安全隐患,而本发明是通过比较主库对应的动态签名和静态签名是否一致,来验证主库是否安全,从而保证app的安全。

由于在app内,主库的可执行文件和动态库的可执行文件是分离的,并且是等价存在的,共同组成了一个app的执行文件。因此上述实施例中的认证过程是可以反向过来的。但是两者的目的是不一样的:认证主库是为了保护主库和app的安全,而认证动态库则是为了保证动态库和app的安全。它们相互互补,共同维护app的安全。

为了描述方便,在本发明中,令认证主库安全性的方法为正向认证过程,认证动态库安全性的方法为正向认证过程。作为本发明的再一个实施例,可以进一步地对动态库进行反向认证,从而实现双向认证,提高app的安全性。

图2是根据本发明一个可参考实施例的对应用程序进行安全认证的方法的主要流程的示意图。作为本发明的又一个实施例,所述对应用程序进行安全认证的方法可以包括:

步骤201,获取主库的动态属性数据,对所述动态属性数据进行签名,生成第一动态签名;

步骤202,获取存储在动态库中的所述主库的静态属性数据,对所述静态属性数据进行签名,生成第一静态签名;

步骤203,比较所述第一动态签名和第一静态签名是否一致,以完成对主库的安全认证;

步骤204,获取动态库的动态属性数据,对所述动态属性数据进行签名,生成第二动态签名;

步骤205,获取存储在主库中的所述动态库的静态属性数据,对所述静态属性数据进行签名,生成第二静态签名;

步骤206,比较所述第二动态签名和第二静态签名是否一致,以完成对动态库的安全认证。

需要指出的是,步骤201、步骤202、步骤203为正向认证过程,步骤204、步骤205、步骤206为正向认证过程。作为本发明的又一个实施例,可以先执行正向认证过程,再执行反向认证过程;也可以先执行反向认证过程,再执行正向认证过程,均可以达到本发明的技术效果。

由于主库和动态库在app内的位置不同,存在方式不同,引用方式不同,以及库本身的代码量等不同,所以他们存在的安全问题也就有差异,那么反向认证过程保护的内容也就有差异。

以下对步骤204、步骤205和步骤206的执行进行详细说明。

步骤204,获取动态库的动态属性数据,对所述动态属性数据进行签名,生成第二动态签名。

可选地,所述动态属性数据包括属性的动态值,其中,所述属性包括应用程序的属性和/或自定义的属性。可选地,所述应用程序的属性可以包括boundid和/或动态库的名字,所述自定义的属性可以包括被注入或挂钩标识和/或资源标识中的至少一种。

(1)boundid:动态库的boundid在生成动态库的同时就已确定,可以与主库的boundid一样,也可以与主库的boundid不一样。

(2)动态库的名字:动态库可执行文件的名字,可以通过获取运行在动态库可执行文件类的信息,得到动态库的名字。

(3)被注入或者挂钩标识;通过获取主库中n个敏感类的信息,判断它们所在的可执行文件与动态库的可执行文件是否一致,如果不一致,再去判断它们所在的可执行文件与主库的可执行文件是否相同,如果都不相同,那么则认为该敏感类被挂钩(hook)或者app被注入,就会返回被注入或者挂钩标识(比如hook);其他情况,则返回正常标识(比如normal_hook)。

(4)资源标识:通过随机认定几个动态库资源文件,判断这些动态库资源文件是否都存在。如果都存在返回正常标识(resource);如果某些不存在,那么返回异常标识(resource_failure)。这样做的目的是将动态库的资源文件与动态库的可执行文件绑定在了一起,保证动态的安全,从而保证app的安全。

需要说明的是,所述字符串的拼接顺序可以预先设定,获取的属性也可以预先设定。而且,可以根据不同的需求,获取更多动态库的动态属性信息,从而更多方面的保证app和动态库的安全。

作为本发明的又一个实施例,步骤204包括:分别获取动态库对应的各个属性的动态值,然后将各个属性的动态值按照预设的顺序拼接成字符串,再所述字符串进行签名,生成第二动态签名。

需要指出的是,步骤204中拼接属性值的顺序可以与步骤101中的顺序一样,只是需要使用到的拼接字符串值不同。当然,步骤204中拼接属性值的顺序可以与步骤101中的顺序也可以不一样。

可选地,采用不可逆加密算法对所述字符串进行签名。具体地,可以通过代码调用的方式,分别获取动态库对应的各个属性的动态值。根据获得的动态值,按照预设的顺序拼接成一个字符串,然后对该字符串进行md5处理,处理的结果即为第二动态签名。

作为本发明的一个实施例,可以由主库向动态库发起请求,以获得第二动态签名。请求方式与步骤101中所描述的方法类似,不再赘述。可选地,请求动态起签名的操作可以发生在动态库的c语言构造函数里面。作为本发明的又一个实施例,也可以由独立的管理程序向动态库发起请求,以获得第二动态签名,也能够达到与上述方案相同或者相似的技术效果。

步骤205,获取存储在主库中的所述动态库的静态属性数据,对所述静态属性数据进行签名,生成第二静态签名。

在该步骤中,分别获取动态库对应的各个属性的静态值,然后将各个属性的静态值按照预设的顺序拼接成字符串,再所述字符串进行加密处理,生成第二静态签名。可以预先将所述静态值存储在主库中。

需要指出的是,在步骤205中,拼接字符串所采用的属性与步骤204中所采用的属性相同,不同的是,步骤205中所采用的是属性的静态值,而步骤204中所采用的是属性的动态值。而且,在步骤205中,拼接字符串的顺序与步骤204中拼接字符串的顺序相同。所述字符串的拼接顺序可以预先设定,获取的属性也可以预先设定,从而使步骤204和步骤205均按照相同的属性获取属性值,并按照相同的顺序拼接这些属性值。因此,也需要采用相同的方法对字符串进行加密处理,例如采用md5对字符串进行加密处理,处理的结果即为第一静态签名,以使第二动态签名与第二静态签名具有可比较性。

需要指出的是,可以先执行步骤204,再执行步骤205;也可以先执行步骤204,再执行步骤205;还可以同时执行步骤204、步骤205。

步骤206,比较所述第二动态签名和第二静态签名是否一致,以完成对动态库的安全认证。

如果第二动态签名和第二静态签名的值不一致,说明动态库不再安全。如果第二动态签名和第二静态签名的值一致,说明动态库仍然是安全的。

在该步骤中,比较第二动态签名和第二静态签名的值是否一致。如果不一致,则对比较的结果做异常处理(例如退出app、抛出异常、上报服务端等等);如果一致,则结束,从而完成对动态库的安全认证。这样就阻止了破坏app行为的继续执行,可见,本发明实施例提供的方法可以比较全面地保证app的安全。

因此,本发明实施例提供的方法可以实现从app主库可执行文件到动态库的签名认证过程和从app动态库到主库可执行文件的签名认证过程,从而保证了app的安全。

由此可见,本发明实施例提供的方法能够使主库、动态库和资源文件绑定在一起,加固了app,提高了app的安全水平,也提高了app被逆向的门槛,使app更加安全健康地运行在终端上。该方法对防止app被hook、被注入,动态库被改变被替换或者被单独引用等,具有显著的作用。

作为本发明的又一个实施例,所述方法还包括:对所述主库的静态属性数据进行加密,以密文的形式存储在动态库中。

具体地,对字符串进行加密,将密文以字符串常量的形式存储在动态库中,以备使用。可选地,可以对拼接后的字符串进行加密,那么在解密后就不再进行拼接。可选地,可以分别对未拼接的字符串(即各个属性的静态值)进行加密,那么在解密后,需要拼接字符串。

作为本发明的再一个实施例,所述加密的方法包括:采用对称加密算法加随机字符串的形式对所述静态属性数据进行加密。可选地,对称加密算法可以是三重数据加密算法,并在密文的前后加上随机字符串,随机字符串的字符数不限。可选地,将明文采用标准的3des(tripledataencryptionalgorithm,三重数据加密算法)加密,并在密码后的密文字符串前后加上六位的随机字符串,得到最终的加密结果。加随机字符串的目的是避免直接将密文暴露黑客,提高静态属性数据的安全性。

加解密key:由于采用对称加密,所以解密key与加密key相同。加解密key以明文的形式存储在动态库的可执行文件中,加载到内存后,直接传递给加密算法。

加解密偏移量:为了加解密安全,故设了偏移量。加密偏移量和解密偏移量相同,加解密偏移量以明文形式存储在动态库的可执行文件中,加载到内存后,直接传递给加密算法。

六位随机字符串:由0-9,a-z,a-z,=,/等字符组成。首先采用系统方法随机生成一个数字,然后将该数字除以64取余,当结果小于10时,再将该结果除以10取余,那么该过程就可以得到一位0-9的随机数字。同理,如果第一次取余的结果在10-36,37-62,63-64,则分别返回a-z,a-z,=,/的字符。将该过程循环六次,可以得到一个六位的随机字符串。

相应地,在步骤102中,所述获取存储在动态库中的所述主库的静态属性数据,包括:先获取存储在动态库中的所述静态属性数据的密文,然后对所述密文进行解密,从而得到所述主库的静态属性数据的明文。

可选地,对所述密文进行解密的步骤,包括:先去掉密文前后的随机字符串,然后获取解密key和解密偏移量,再采用相应的解密方法对密文进行解密,从而得到明文。

由于解密key是随着app一起进行发布的,很容易暴露在黑客面前,所以要对它进行安全处理。读取app资源文件中的一个简易图片,并将读取到的数据转换为一个字符串,并将字符串进行md5加密,从而得到解密key。

作为本发明的再一个实施例,还可以采用更加复杂的加密算法,例如:1)采用3des和aes(advancedencryptionstandard,高级加密标准,又称rijndael加密法)加密方法相结合。将要加密的明文按照一定比例分成两份,一份采用3des加密,另一份采用aes加密。然后将密文拼接成一个字符串。也可以采用更多的加密算法拼接。2)将密文的每个字符后面加上一个随机字符。字符的生成方法与前文中随机字符串的生成方法相似。也可以是更多的随机字符串组合方式。3)采用白盒加密技术进行加密。

作为本发明的又一个实施例,所述方法还包括:对所述动态库的静态属性数据进行加密,以密文的形式存储在主库中。相应地,在步骤205中,所述获取存储在主库中的所述动态库的静态属性数据,包括:先获取存储在主库中的所述静态属性数据的密文,然后对所述密文进行解密,从而得到所述动态库的静态属性数据的明文。

需要说明的是,对动态库的静态属性数据进行加解密的方法与对主库的静态属性数据进行加解密的方法类似,故在此重复内容不再说明。

可选地,采用调用实现分离方法隐藏所有函数的调用,那么在使用反编译工具进行静态分析的时候,将发现不到调用的是哪个函数。具体地,以函数指针为参数,在函数实现中,调用该函数指针指向的函数,返回该函数执行的结果,并在该函数内部加入一些混淆的代码。

图3是根据本发明实施例的对应用程序进行安全认证的装置,如图3所示,所述对应用程序进行安全认证的装置300包括第一签名模块301、第二签名模块302以及第一对比模块303。其中,所述第一签名模块301获取主库的动态属性数据,对所述动态属性数据进行签名,生成第一动态签名;所述第二签名模块302获取存储在动态库中的所述主库的静态属性数据,对所述静态属性数据进行签名,生成第一静态签名;所述第一对比模块303比较所述第一动态签名和第一静态签名是否一致,以完成对主库的安全认证。

可选地,所述动态属性数据包括属性的动态值,所述静态属性数据包括属性的静态值。其中,所述属性包括应用程序的属性和/或自定义的属性。可选地,所述应用程序的属性可以包括应用程序的唯一标识、应用程序安装包的名字、应用程序安装后显示的名字、主库的名字和动态库的名字中的至少一种,所述自定义的属性可以包括被调试标识、被注入或挂钩标识、越狱标识和资源标识中的至少一种。

所述第一签名模块301分别获取主库对应的各个属性的动态值,然后将各个属性的动态值按照预设的顺序拼接成字符串,再所述字符串进行签名,生成第一动态签名。可选地,采用不可逆加密算法对所述字符串进行签名。

所述第二签名模块302分别获取主库对应的各个属性的静态值,然后将各个属性的静态值按照预设的顺序拼接成字符串,再所述字符串进行加密处理,生成第一静态签名。可以预先将所述静态值存储在动态库中。可选地,采用不可逆加密算法对按照预设顺序拼接而成的字符串进行签名。

需要指出的是,第二签名模块302拼接字符串所采用的属性与第一签名模块301所采用的属性相同,不同的是,第二签名模块302所采用的是属性的静态值,而第一签名模块301所采用的是属性的动态值。而且,第二签名模块302拼接字符串的顺序与第一签名模块301拼接字符串的顺序相同。

所述字符串的拼接顺序可以预先设定,获取的属性也可以预先设定,从而使第一签名模块301和第二签名模块302均按照相同的属性获取属性值,并按照相同的顺序拼接这些属性值。因此,也需要采用相同的方法对字符串进行加密处理,例如采用md5对字符串进行加密处理,以使第一动态签名与第一静态签名具有可比较性。

静态签名的目的是对动态签名的值进行验证,静态签名能够验证动态签名的值是否正常。如果第一动态签名和第一静态签名的值不一致,说明主库不再安全。如果第一动态签名和第一静态签名的值一致,说明主库仍然是安全的。

所述第一对比模块303比较第一动态签名和第一静态签名的值是否一致。如果不一致,则对比较的结果做异常处理(例如退出app、抛出异常、上报服务端等等);如果一致,则结束,从而完成对主库的安全认证。这样就阻止了破坏app行为的继续执行,可见,本发明实施例提供的装置可以比较全面地保证app的安全。

可选地,所述装置还包括第三签名模块、第四签名模块和第二对比模块,所述第三签名模块获取动态库的动态属性数据,对所述动态属性数据进行签名,生成第二动态签名,所述第四签名模块获取存储在主库中的所述动态库的静态属性数据,对所述静态属性数据进行签名,生成第二静态签名,所述第二对比模块比较所述第二动态签名和第二静态签名是否一致,以完成对动态库的安全认证。

可选地,所述动态属性数据包括属性的动态值,所述静态属性数据包括属性的静态值。其中,所述属性包括应用程序的属性和/或自定义的属性。可选地,所述应用程序的属性可以包括应用程序的唯一标识和/或动态库的名字,所述自定义的属性可以包括被注入或挂钩标识和/或资源标识中的至少一种。

所述第三签名模块分别获取动态库对应的各个属性的动态值,然后将各个属性的动态值按照预设的顺序拼接成字符串,再所述字符串进行签名,生成第二动态签名。所述第四签名模块分别获取动态库对应的各个属性的静态值,然后将各个属性的静态值按照预设的顺序拼接成字符串,再所述字符串进行加密处理,生成第二静态签名。可以预先将所述静态值存储在主库中。可选地,采用不可逆加密算法对按照预设顺序拼接而成的字符串进行签名。

需要指出的是,第四签名模块拼接字符串所采用的属性与第三签名模块所采用的属性相同,不同的是,第四签名模块所采用的是属性的静态值,而第三签名模块所采用的是属性的动态值。而且,第四签名模块拼接字符串的顺序与第三签名模块拼接字符串的顺序相同。

所述字符串的拼接顺序可以预先设定,获取的属性也可以预先设定,从而使第三签名模块和第四签名模块均按照相同的属性获取属性值,并按照相同的顺序拼接这些属性值。因此,也需要采用相同的方法对字符串进行加密处理,例如采用md5对字符串进行加密处理,以使第二动态签名与第二静态签名具有可比较性。

所述第二对比模块比较第二动态签名和第二静态签名的值是否一致。如果不一致,则对比较的结果做异常处理(例如退出app、抛出异常、上报服务端等等);如果一致,则结束,从而完成对动态库的安全认证。这样就阻止了破坏app行为的继续执行,可见,本发明实施例提供的方法可以比较全面地保证app的安全。

可选地,所述装置还包括第一加密模块和/或第二加密模块,所述第一加密模块对所述主库的静态属性数据进行加密,以密文的形式存储在动态库中,所述第二加密模块对所述动态库的静态属性数据进行加密,以密文的形式存储在主库中。

相应地,在该实施例中,所述第二签名模块302获取存储在动态库中的所述静态属性数据的密文,对所述密文进行解密,得到所述主库的静态属性数据的明文;所述第四签名模块获取存储在主库中的所述静态属性数据的密文,对所述密文进行解密,得到所述动态库的静态属性数据的明文。

具体地,第一加密模块和/或第二加密模块对字符串进行加密,将密文以字符串常量的形式存储在动态库和/或主库中,以备使用。可选地,可以对拼接后的字符串进行加密,那么在解密后就不再进行拼接。可选地,可以分别对未拼接的字符串进行加密,那么在解密后,需要拼接字符串。

作为本发明的再一个实施例,所述加密的方法包括:采用对称加密算法加随机字符串的形式对所述静态属性数据进行加密。可选地,对称加密算法可以是三重数据加密算法,并在密文的前后加上随机字符串,随机字符串的字符数不限。可选地,将明文采用标准的3des加密,并在密码后的密文字符串前后加上六位的随机字符串,得到最终的加密结果,以提高静态属性数据的安全性。

可选地,对所述密文进行解密的步骤,包括:先去掉密文前后的随机字符串,然后获取解密key和解密偏移量,再采用相应的解密方法对密文进行解密,从而得到明文。

作为本发明的再一个实施例,还可以采用更加复杂的加密算法,例如:1)采用3des和aes(advancedencryptionstandard,高级加密标准,又称rijndael加密法)加密方法相结合。将要加密的明文按照一定比例分成两份,一份采用3des加密,另一份采用aes加密。然后将密文拼接成一个字符串。也可以采用更多的加密算法拼接。2)将密文的每个字符后面加上一个随机字符。字符的生成方法与前文中随机字符串的生成方法相似。也可以是更多的随机字符串组合方式。3)采用白盒加密技术进行加密。

根据上面所述的各种实施例,可以看出本发明通过采用比较主库对应的动态签名和静态签名是否一致的技术手段,所以克服了app面临着堵多安全隐患的技术问题,本发明是通过比较主库对应的动态签名和静态签名是否一致,来验证主库是否安全,从而保证app的安全。进一步地,本发明是通过比较动态库对应的动态签名和静态签名是否一致,来验证动态库是否安全,实现主库和动态库双向认证,提高了app的安全性。

需要说明的是,在本发明所述对应用程序进行安全认证的装置的具体实施内容,在上面所述对应用程序进行安全认证的方法中已经详细说明了,故在此重复内容不再说明。

图4示出了可以应用本发明实施例对应用程序进行安全认证的方法或对应用程序进行安全认证的装置的示例性系统架构400。

如图4所示,系统架构400可以包括终端设备401、402、403,网络404和服务器405。网络404用以在终端设备401、402、403和服务器405之间提供通信链路的介质。网络404可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备401、402、403通过网络404与服务器405交互,以接收或发送消息等。终端设备401、402、403上可以安装有各种通讯客户端应用,例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备401、402、403可以是具有显示屏并且支持网页浏览的各种电子设备,包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器405可以是提供各种服务的服务器,例如对用户利用终端设备401、402、403所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理,并将处理结果(例如目标推送信息、产品信息——仅为示例)反馈给终端设备。

需要说明的是,本发明实施例所提供的对应用程序进行安全认证的方法一般在公共场所的终端设备401、402、403上执行,相应地,所述对应用程序进行安全认证的装置一般设置在公共场所的终端设备401、402、403中。

应该理解,图4中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端设备、网络和服务器。

下面参考图5,其示出了适于用来实现本发明实施例的终端设备的计算机系统500的结构示意图。图5示出的终端设备仅仅是一个示例,不应对本发明实施例的功能和使用范围带来任何限制。

如图5所示,计算机系统500包括中央处理单元(cpu)501,其可以根据存储在只读存储器(rom)502中的程序或者从存储部分508加载到随机访问存储器(ram)503中的程序而执行各种适当的动作和处理。在ram503中,还存储有系统500操作所需的各种程序和数据。cpu501、rom502以及ram503通过总线504彼此相连。输入/输出(i/o)接口505也连接至总线504。

以下部件连接至i/o接口505:包括键盘、鼠标等的输入部分506;包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分507;包括硬盘等的存储部分508;以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至i/o接口505。可拆卸介质511,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器510上,以便于从其上读出的计算机程序根据需要被安装入存储部分508。

特别地,根据本发明公开的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本发明公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分509从网络上被下载和安装,和/或从可拆卸介质511被安装。在该计算机程序被中央处理单元(cpu)501执行时,执行本发明的系统中限定的上述功能。

需要说明的是,本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、rf等等,或者上述的任意合适的组合。

附图中的流程图和框图,图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现,也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中,例如,可以描述为:一种处理器包括第一签名模块、第二签名模块和第一对比模块,其中,这些模块的名称在某种情况下并不构成对该模块本身的限定。

作为另一方面,本发明还提供了一种计算机可读介质,该计算机可读介质可以是上述实施例中描述的设备中所包含的;也可以是单独存在,而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被一个该设备执行时,使得该设备包括:获取主库的动态属性数据,对所述动态属性数据进行签名,生成第一动态签名;获取存储在动态库中的所述主库的静态属性数据,对所述静态属性数据进行签名,生成第一静态签名;比较所述第一动态签名和第一静态签名是否一致,以完成对主库的安全认证。

根据本发明实施例的技术方案,因为采用比较主库对应的动态签名和静态签名是否一致的技术手段,所以克服了app面临着堵多安全隐患的技术问题,本发明是通过比较主库对应的动态签名和静态签名是否一致,来验证主库是否安全,从而保证app的安全。进一步地,本发明是通过比较动态库对应的动态签名和静态签名是否一致,来验证动态库是否安全,实现主库和动态库双向认证,提高了app的安全性。

上述具体实施方式,并不构成对本发明保护范围的限制。本领域技术人员应该明白的是,取决于设计要求和其他因素,可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等,均应包含在本发明保护范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1