著录项信息
专利名称 | 本地服务单元认证安卓客户端应用程序的方法 |
申请号 | CN201210344786.X | 申请日期 | 2012-09-18 |
法律状态 | 暂无 | 申报国家 | 暂无 |
公开/公告日 | 2013-01-23 | 公开/公告号 | CN102891843A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | H04L29/06 | IPC分类号 | H;0;4;L;2;9;/;0;6;;;H;0;4;L;9;/;3;2查看分类表>
|
申请人 | 北京深思洛克软件技术股份有限公司 | 申请人地址 | 北京市海淀区西北旺东路10号院东区5号楼5层510
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 北京深思数盾科技股份有限公司 | 当前权利人 | 北京深思数盾科技股份有限公司 |
发明人 | 不公告发明人 |
代理机构 | 暂无 | 代理人 | 暂无 |
摘要
本发明提供了一种本地服务程序认证安卓客户端应用程序的方法。该方法先对客户端应用程序进行签名生成认证信息文件,当客户端应用程序在安卓系统中运行时,本地服务程序对认证信息文件进行认证,认证通过之后客户端应用程序才可正常使用本地服务程序提供的服务。通过本发明提供的方法,使得经篡改的客户端应用程序无法获取本地服务程序的功能,区隔了合法软件和恶意软件,确保了安卓系统和网络的安全性。
本地服务单元认证安卓客户端应用程序的方法\n技术领域\n[0001] 本发明涉及安卓系统中应用程序安全保护领域,特别涉及一种本地服务单元认证安卓客户端应用程序的方法。\n背景技术\n[0002] 在安卓(Android)系统下,为了防止盗版软件的猖獗,谷歌开发了安卓签名机制,安卓签名机制标明了安卓客户端应用程序的发行机构,通过对比客户端应用程序的签名情况,来判断该客户端应用程序是否由“官方”发行,而不是被破解者篡改过重新签名打包的“盗版软件”。\n[0003] 安卓系统要求每一个安装进系统的应用程序都是经过数字证书签名的,数字证书的私钥则保存在程序开发者的手中。安卓系统将数字证书用来标识应用程序的作者和在应用程序之间建立信任关系,数字证书不是用来决定最终用户可以安装哪些应用程序。这个数字证书并不需要权威的数字证书签名机构认证,它只是用来让应用程序包自我认证的。\n[0004] 通过安卓签名工具签名后的客户端应用程序包中多了一个META-INF的文件夹,该文件夹中包含了加密信息,其他的文件则没有任何改变,这样就可以很容易去掉原有的签名信息,破解应用程序包,对代码篡改,生成恶意软件,然后重新签名,危害了开发者利益,甚至威胁到手机和网络的安全。\n[0005] 为了更进一步维护开发者的版权利益,防止盗版软件的猖獗,保护安卓系统下应用软件的安全,有开发者做了改进,增加安卓客户端应用程序包反编译的难度。目前已提出一种解决方案,意在解决在安卓系统下盗版应用的问题。解决方案如下:服务商提供一个本地服务单元(比如,本地服务程序),本地服务程序在安卓系统下作为原生service(服务),与安卓系统同时启动,在后台一直运行,本地服务程序提供如内存加密、文件加密、云服务器端函数远程调用等功能。安卓客户端应用程序调用本地服务程序提供的接口将关键值(比如游戏类应用程序中的金币值)、关键文件、关键代码等通过本地服务程序进行加密变换,在客户端应用程序运行时,根据客户端应用程序的调用需求对加密对象用本地服务程序进行实时解密运行,使得客户端应用程序难以进行反编译和静态分析,从而实现了对安卓系统应用的有效保护。\n[0006] 在这一过程中,客户端应用程序的关键值和关键代码通过本地服务程序存储在云服务器端,当客户端应用程序向云服务器端存储或获取关键值等需求时,需调用本地服务程序的远程(云服务器端)调用接口,由本地服务程序向云服务器端通信。本地服务程序作为客户端应用程序和云服务器端的中转站,起到连接两端桥梁的作用。\n[0007] 但是如果有一些恶意的客户端应用程序利用现有的本地服务程序不断地向云服务器端进行恶意操作(比如不断地向云服务器端存金币或者获取某些关键值)以获取利益,那么本地服务程序则无法辨别该客户端应用程序是否是从正规渠道下载下来的客户端应用程序,而不是用户自己编写的恶意客户端应用程序。因此,存在这样一种技术需求,即需要提供一种方法,该方法能够辨别安卓客户端应用程序是否被替换,从而及时阻止恶意客户端应用程序的执行,防止客户端应用程序的应用代码被恶意篡改。\n发明内容\n[0008] 为了防止安卓系统中有恶意软件利用本地服务程序修改云服务器端数据以谋取利益,本发明提供了一种本地服务程序认证客户端应用程序的方法,所述方法包括如下步骤:\n[0009] 步骤1:采用加密算法对所述应用程序的客户端应用程序包进行加密,生成认证信息文件,其中所述客户端应用程序包对应于所述认证信息文件;\n[0010] 步骤2:在安卓系统后台运行本地服务单元,;\n[0011] 步骤3:所述应用程序与所述本地服务单元建立binder通信;\n[0012] 步骤4:所述本地服务单元根据所述应用程序发送的信息搜索所述客户端应用程序包;\n[0013] 步骤5:如果搜索所述客户端应用程序包成功,则执行步骤6;否则,断开所述本地服务单元与所述应用程序的binder通信;\n[0014] 步骤6:所述本地服务单元读取所述认证信息文件;\n[0015] 步骤7:所述本地服务单元对所述认证信息文件进行认证;\n[0016] 步骤8:如果认证成功,则所述应用程序正常运行;否则,断开所述本地服务单元与所述应用程序的binder通信。\n[0017] 根据本发明的一个方面,在所述步骤1中,所述认证信息文件存于所述客户端应用程序包内部,或者存在远程云服务器端。\n[0018] 根据本发明的一个方面,在所述步骤4中,所述本地服务单元根据所述应用程序发送的用户ID和进程ID搜索对应的所述客户端应用程序包。\n[0019] 根据本发明的一个方面,在所述步骤4中,所述客户端应用程序包是APK包。\n[0020] 根据本发明的一个方面,在所述步骤6中,如果读取不到所述认证信息文件,所述本地服务单元向远程云服务器端搜索所述认证信息文件;如果在所述远程云服务器端搜索不到所述认证信息文件,则断开所述本地服务单元与所述应用程序的binder通信。\n[0021] 根据本发明的一个方面,如果搜索到所述认证信息文件,并且所述认证信息文件中包含密文和加密算法,则在步骤7中根据加密算法的类型选择相应的认证方法对认证信息文件中的密文进行认证。\n[0022] 根据本发明的一个方面,如果采用单向加密算法,由所述本地服务单元根据加密算法对所述客户端应用程序包进行加密以生成密文,然后将生成的所述密文与所述的认证信息文件中的密文进行认证;\n[0023] 如果采用双向加密算法,则由所述本地服务单元获取密钥,来解密所述认证信息文件中的密文。\n[0024] 根据本发明的一个方面,如果采用双向加密算法,则双向加密算法的密钥存储在所述本地服务单元的包中,或者存在云服务器端。\n[0025] 根据本发明的一个方面,在所述步骤8中,认证成功后,则所述应用程序正常运行,并且所述应用程序被允许调用所述本地服务单元的所提供的服务。\n附图说明\n[0026] 图1为本发明的流程示意图;\n[0027] 图2为本发明中本地服务程序与客户端应用程序之间建立binder通信过程的示意图;\n[0028] 图3为本发明实施例一中本地服务程序对客户端应用程序的认证过程的示意图。\n[0029] 图4为本发明实施例二中本地服务程序对客户端应用程序的认证过程的示意图。\n具体实施方式\n[0030] 为了防止安卓系统中有恶意应用程序利用本地服务单元(在下文中称为本地服务程序)修改云服务器端数据,本发明提供了一种通过本地服务程序认证客户端应用程序的方法。\n[0031] 本地服务程序认证客户端应用程序的方法为:\n[0032] 采用加密算法对客户端应用程序包加密,生成认证信息文件,其中客户端应用程序包对应于一个认证信息文件;根据本发明的一个实施例,该认证信息文件的存储位置由开发者决定,可以存于客户端应用程序包内,也可以存于远程服务器中。\n[0033] 客户端应用程序启动;\n[0034] 本地服务程序与客户端应用程序建立binder通信;\n[0035] 本地服务程序与客户端应用程序双方建立binder通信后,本地服务程序根据客户端应用程序的用户ID和进程ID搜索对应的客户端应用程序包,例如,客户端应用程序包是安卓系统下常见的.APK包;\n[0036] 如果没有搜索到客户端应用程序包,则本地服务程序断开与客户端应用程序的binder通信,使得客户端应用程序无法获取本地服务程序提供的服务;\n[0037] 如果搜索到客户端应用程序包,则由本地服务程序读取客户端应用程序包中的认证信息文件;\n[0038] 如果读取不到认证信息文件,则存在两种可能:一是客户端应用程序包不完整,二是生成该认证信息文件的加密算法不同导致认证信息文件存储的位置不同,也就是说,该客户端应用程序的认证信息文件可能存于云服务器端;然后本地服务程序向云服务器端搜索认证信息文件,如果在云服务器端搜索不成功,则该客户端应用程序包确实不完整或者不合法,则本地服务程序将该客户端应用程序断开binder通信,不向这个客户端应用程序提供诸如加密功能服务;如果本地服务程序在云服务器端搜索到了认证信息文件,而且该认证信息文件包含密文和加密算法,那么根据本发明的一个实施例,本地服务程序根据加密算法对客户端应用程序包进行加密以生成密文,然后将生成的密文与认证信息文件中的密文进行比对认证。此外,根据本发明的一个实施例,除了上述单向加密算法的处理方式,还可用以下处理方式:先判断加密算法的类型,如果是单向加密算法,那么本地服务程序根据加密算法对客户端应用程序包进行加密以生成密文,然后将生成的密文与认证信息文件中的密文进行比对认证;若是双向加密算法,就用本地服务程序获取的密钥解密(认证)客户端应用程序的密文。\n[0039] 如果认证不成功,则本地服务程序与客户端应用程序断开binder通信,不向该客户端应用程序提供服务,如果认证成功,则客户端应用程序正常执行。\n[0040] 图1表示了其中的大部分处理流程。\n[0041] 所述的客户端应用程序包对应的认证信息文件是指经加密算法对客户端应用程序包加密所产生的密文。该认证信息文件根据加密算法的不同存储的位置也不同,认证信息文件可存放于客户端应用程序包内,也可存放于云服务器端,这是由所使用的加密算法的特点决定的。根据认证信息文件存储的位置不同,所对应的本地服务程序认证客户端应用程序的方法也不同。认证信息文件根据需要,除了包含密文,也可以包括加密算法、密钥存储位置等其它信息。\n[0042] 加密算法大体分为双向加密和单向加密。单向加密严格上说是一种摘要算法,是非可逆加密,例如MD5算法,其作用是将任意长度的信息变换成一定长的十六进制数字串(称作“摘要信息”),同时保证不同信息的摘要信息彼此不同。针对这种单向加密的算法,认证信息文件包括密文即摘要信息,加密算法为MD5等信息。根据单向加密的特征,该认证信息文件可存储在云服务器端,那么在客户端应用程序与本地服务程序建立连接后,本地服务程序从云服务器端下载认证信息文件,本地服务程序根据认证信息文件中的加密算法对客户端应用程序包重新生成密文与云服务器端下载的认证信息文件的密文进行比对验证,从而判断客户端应用程序是否合法。\n[0043] 根据本发明的一个实施例,单向加密的认证信息文件也可存于客户端应用程序包内,那么在客户端应用程序与本地服务程序建立连接后,本地服务程序根据认证信息文件中的加密算法对客户端应用程序包重新生成的密文与客户端应用程序包内的认证信息文件的密文进行比对验证,从而判断客户端应用程序是否合法。\n[0044] 双向加密算法分为对称加密和非对称加密,以非对称加密算法为例,根据公钥和私钥对,由私钥将客户端应用程序加密形成密文,那么该客户端应用程序的认证信息文件包括密文、公钥存储的位置等信息,其中公钥存储的位置可以在本地服务程序包内,也可以在云服务器端。本地服务程序根据认证信息文件中公钥存储的位置信息获取公钥,根据获取的公钥去验证客户端应用程序的认证信息文件的密文。\n[0045] 所述的本地服务程序在安卓系统下表现为一个原生service(服务),与安卓系统一同启动,在后台运行,提供服务。本地服务程序提供认证客户端应用程序是否合法的服务,其同时也可以提供如内存加密、文件加密、远程(云服务器端)函数调用等功能模块,一方面为客户端应用程序提供本地加密服务,另一方面作为客户端应用程序与云服务器端的中转站与云服务器端进行数据交互。\n[0046] 本地服务程序与客户端应用程序的交互是基于binder的Client-Server的通信方式。binder是安卓系统进程间通信(IPC)方式之一。\n[0047] binder通信概述:binder通信是一种client-server的通信结构,1.从表面上来看,是client通过获得一个server的代理接口,对server进行直接调用;2.实际上,代理接口中定义的方法与server中定义的方法是一一对应的;3.client调用某个代理接口中的方法时,代理接口的方法会将client传递的参数打包成为Parcel对象;4.代理接口将该Parcel发送给内核中的binderdriver;5.server会读取binderdriver中的请求数据,如果是发送给自己的,解包Parcel对象,处理并将结果返回;6.整个的调用过程是一个同步过程,在server处理的时候,client会block住。\n[0048] 安卓系统为每个安装好的APK分配UID,故UID是鉴别应用身份的重要标志,在安卓系统下,每一个不同的程序都有一个唯一的UID,一个应用里面可以有多个PID,binder利用通讯自带的UID/PID来实现进程和数据的隔离。binder 是基于Client-Server通信模式,在传输过程中,Client端发送的信息中添加安卓系统分配的UID/PID,这样Server端就可以根据发送方的UID/PID来鉴别Client端的身份,安全性高。在安卓系统中,本地服务程序作为binder的Server端,客户端应用程序作为binder的Client端。\n[0049] ServiceManager概述:ServiceManager是一个Linux级的进程,是service的管理器。任何service在被使用之前,均要向SM(ServiceManager)注册,同时客户端需要访问某个service时,应该首先向SM查询是否存在该服务。如果SM存在这个service,那么会将该service的handle返回给client,handle是每个service的唯一标识符。\n[0050] 和DNS类似,ServiceManager的作用是将字符形式的binder名字转化成Client中对该binder的引用,使得Client能够通过binder名字获得对Server中binder实体的引用。注册了名字的binder叫实名binder,就象每个网站除了有IP地址外还有自己的网址。Server创建了binder实体,为其取一个字符形式,可读易记的名字,将这个binder连同名字以数据包的形式通过binder驱动发送给ServiceManager,通知ServiceManager注册一个名叫张三的binder,它位于某个Server中。驱动为这个穿过进程边界的binder创建位于内核中的实体节点以及ServiceManager对实体的引用,将名字及新建的引用打包传递给ServiceManager。ServiceManager收数据包后,从中取出名字和引用填入一张查找表中。\n[0051] ServiceManager管理service进程,本地服务程序先在ServiceManager注册名字,成为实名binder,比如一个叫张三的binder对应着本地服务程序的引用。客户端应用程序作为相对于本地服务程序的Client端,它通过ServiceManager搜索名叫张三对应的binder引用,该引用即为本地服务程序的binder引用,客户端应用程序通过ServiceManager回复的binder引用向本地服务程序发送请求。\n[0052] 双方建立连接后,开始通信,本地服务程序根据 binder自带客户端应用程序在安卓系统下的用户ID、进程ID(UID/PID)号去识别客户端应用程序的身份,进而实现诸如进程间数据隔离、客户端应用程序是否合法的认证等功能。\n[0053] 综上所述,本发明有效地防止了非法客户端应用程序恶意篡改应用数据造成的破坏。\n[0054] 为使本发明的目的、技术方案及优点更加清楚明白,以下参照图并给出具体的实施例,对本发明进一步详细说明。本领域的技术人员都应清楚,下述实施例仅仅是实现本发明的具体实现情况,而非对本发明的具体限制。本领域的技术人员根据下面具体实施例的技术教导,完全能够在不脱离本发明的范围的情况下进行各种改进、替换。\n[0055] 实施例一:\n[0056] 在本实施例中,生成客户端程序包的认证信息文件的加密算法为双向加密算法中的非对称加密算法,本实施例采用RSA 私钥对安卓客户端程序包APK中的class.dex文件加密。生成的认证信息文件存储在客户端应用程序包内部或者云服务器端。\n[0057] 图2是本地服务程序与客户端应用程序建立binder通信的过程。本地服务程序安装后随着安卓系统的启动一直在后台运行,提供例如内存加密、文件加密和远程(云服务器端)函数调用等功能。\n[0058] 客户端应用程序要想获得本地服务程序提供的服务,要先与本地服务程序建立binder通信。图2主要包括三个模块,分别为ServiceManager、Service、Client。\nServiceManager用来管理Service,Service用来管理Client。根据本发明的一个具体实施方式,本地服务程序对应Service模块,客户端应用程序对应Client模块。\n[0059] 本地服务程序先在ServiceManager注册服务。例如注册了一个叫做ls 的binder,ServiceManager管理一个表,表中维护着一个叫ls的binder引用。\n[0060] 客户端应用程序启动,向ServiceManager发送请求获取本地服务程序 binder的引用。\n[0061] Client端向ServiceManager请求访问叫“ls”的binder引用,ServiceManager端通过查找名字叫做”ls”对应的binder引用,将该引用作为回复发送给请求的Client端的客户端应用程序。至此,本地服务程序与客户端应用程序建立了binder通信,安卓系统会为每次binder通信自动添加UID、PID信息,从而实现用户和进程间的数据隔离。\n[0062] 图3是本实施例中本地服务程序对客户端应用程序的认证过程。\n[0063] 步骤1:用RSA私钥对APK包内的class.dex文件加密,得到的密文保存在认证信息文件中,例如info.txt文件。公钥的存储位置保存在info.txt文件中,那么info.txt文件就是该客户端应用程序的认证信息文件。根据本发明的一个实施例,认证信息文件可保存在客户端应用程序包内部,也可存于云服务器端。\n[0064] 步骤2:客户端应用程序与本地服务程序建立binder通信,具体过程参见图2。\n[0065] 步骤3:本地服务程序根据客户端应用程序发送信息中附带的UID/PID搜索对应的客户端应用程序包,在安卓系统下应用程序包一般后缀为APK包。\n[0066] 步骤4:搜索客户端应用程序包成功,则执行步骤5;否则断开本地服务程序与客户端程序的binder通信。\n[0067] 步骤5:本地服务程序开始检测搜索到的客户端程序包内是否含有认证信息文件,本例中为info.txt文件,如果存在,则执行步骤7;否则执行步骤6。\n[0068] 步骤6:本地服务程序开始检测云服务器端是否存在搜索到的客户端应用对应的认证信息文件。如果存在,则执行步骤7;否则断开本地服务程序与客户端程序的binder通信。\n[0069] 步骤7:本地服务程序读取认证信息文件的内容,获取公钥存储位置。\n[0070] 步骤8:若公钥存储在云服务器端,则执行步骤9;若公钥存储在本地服务程序包内部,则执行步骤10;若读取不到公钥存储的位置信息,则执行步骤11。\n[0071] 步骤9:公钥存储在云服务器端,本地服务程序通过远程调用函数获取云服务器端的公钥,若获取成功,则执行步骤12;否则断开本地服务程序与客户端应用程序的binder通信。\n[0072] 步骤10:公钥存储在本地服务程序包内部,本地服务程序在自己的程序包内搜索公钥,若搜索成功,则执行步骤12,否则断开本地服务程序与客户端应用程序的binder通信。\n[0073] 步骤11:若在认证信息文件中读取不到公钥存储的位置信息,那么本地服务程序先在本地服务程序自己的程序包内搜索公钥,若搜索成功,则执行步骤12;否则向云服务器端获取公钥;\n[0074] 步骤12:本地服务程序根据获取的公钥去解密认证信息文件的密文,若认证成功,则客户端应用程序可正常运行,并且可调用本地服务程序的服务;若认证不成功,说明客户端应用程序不合法,则断开本地服务程序与客户端应用程序的binder通信。\n[0075] 实施例二:\n[0076] 本实施例采用单向加密算法的MD5对客户端应用程序包加密,该算法常用于文件校验,不管文件多大,经MD5后都能生成唯一的MD5值。\n[0077] 本例的认证信息文件包括MD5值和相应的单向加密算法。如果客户端应用程序有变动,用MD5算法加密产生的MD5值一定不同,根据这一原理来实现对客户端应用程序的认证。\n[0078] 图4是本实施例的流程示意图,描述了在单向加密算法下本地服务程序对客户端应用程序的认证过程。\n[0079] 步骤1:用MD5算法对客户端应用程序包加密,产生的MD5值和加密算法组成的认证信息文件,认证信息文件可存储在云服务器端也可存于客户端应用程序包内部。\n[0080] 步骤2:客户端应用程序与本地服务程序建立binder通信,具体过程参见图2。\n[0081] 步骤3:本地服务程序根据客户端应用程序发送信息中附带的UID/PID搜索对应的客户端应用程序包,在安卓系统下应用程序包一般后缀为APK包。\n[0082] 步骤4:搜索客户端应用程序包成功,则执行步骤5;否则断开本地服务程序与客户端程序的binder通信。\n[0083] 步骤5:本地服务程序检测客户端应用程序包是否存在认证信息文件,若存在,则执行步骤7;否则执行步骤6。\n[0084] 步骤6:本地服务程序检测云端是否存在认证信息文件,若存在,则执行步骤7;否则判断客户端应用程序不合法,断开本地服务程序与客户端应用程序的binder通信。\n[0085] 步骤7:本地服务程序读取认证信息文件中的加密算法,用该加密算法对客户端应用程序包加密产生密文,用该密文与认证信息文件中的密文比对认证,如果认证成功,则执行步骤8;否则断开本地服务程序与客户端应用程序的binder通信。\n[0086] 步骤8:认证成功后,则客户端应用程序可正常运行,并且可调用本地服务程序的服务。\n[0087] 以上所述仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换以及改进等,均应包含在本发明的保护范围之内。
法律信息
- 2023-01-13
专利权人的姓名或者名称、地址的变更
专利权人由北京深思数盾科技股份有限公司变更为北京深盾科技股份有限公司
地址由100193 北京市海淀区西北旺东路10号院东区5号楼5层510变更为100193 北京市海淀区西北旺东路10号院东区5号楼5层510
- 2016-11-16
专利权人的姓名或者名称、地址的变更
专利权人由北京深思数盾科技有限公司变更为北京深思数盾科技股份有限公司
地址由100872 北京市海淀区中关村大街甲59号文化大厦1706室变更为100193 北京市海淀区西北旺东路10号院东区5号楼5层510
- 2015-09-02
专利权的转移
登记生效日: 2015.08.11
专利权人由北京深思洛克软件技术股份有限公司变更为北京深思数盾科技有限公司
地址由100084 北京市海淀区中关村南大街甲6号铸诚大厦1201变更为100872 北京市海淀区中关村大街甲59号文化大厦1706室
- 2015-04-29
- 2013-03-06
实质审查的生效
IPC(主分类): H04L 29/06
专利申请号: 201210344786.X
申请日: 2012.09.18
- 2013-01-23
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有引用任何外部专利数据! |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |