Android平台上基于native服务实现的签名验签方法与流程

本发明涉及android智能电视端云交互业务的数据安全技术领域，特别涉及一种android平台上基于native服务实现的签名验签方法。

背景技术：

android智能电视上支持多样化云端服务器部署的运营业务，如主场景从云端获取呈现页面的部署、广告应用从云端获取广告媒体资源、用户的媒体搜索、个性化推荐、做任务赚积分、参与抽奖等服务，都需要电视与云端业务服务器的信息交换来支持。当云端服务器被终端恶意伪装攻击、重放攻击时，很可能被流量冲击导致系统瘫痪；终端请求数据也可能被恶意窃取和篡改，使得终端显示内容异常，甚至非法内容，导致严重的是后果。

因此，智能电视上端云业务中的交互安全非常重要，是提供稳定可靠服务的基础，受到各家智能电视厂商的重视。

技术实现要素：

本发明的目的是克服上述背景技术中不足，提供一种android平台上基于native服务实现的签名验签方法，可在android智能电视中实现核心native服务，用于封装各种加解密、hash算法、签名、验签处理；终端应用与业务云端发送请求、获取应答时基于该native服务实现双向验签和关键数据的加密处理，保证端云业务数据交互的安全运营，防止伪设备网络攻击、重要数据篡改、关键数据泄露等安全风险。

为了达到上述的技术效果，本发明采取以下技术方案：

android平台上基于native服务实现的签名验签方法，具体包括以下步骤：

a.终端应用将业务数据及安全参数传给native服务实施签名，调用成功返回终端数字签名信息；其中，所述安全参数至少包含时间戳、随机数、secretkey；

b.终端发送携带安全参数和数字签名信息的业务请求给云端；

c.云端接收到请求报文后解析出业务数据，并基于安全sdk实现验签处理，若验签通过则向终端返回业务数据正常处理，否则，丢弃请求报文；

d.云端对通过验签的请求进行回应处理，对业务数据结合安全参数，调用安全sdk实现云端数字签名；

e.云端将携带数字签名的报文发送回终端；

f.终端应用解析回应报文，并基于native服务实现验签处理，验签不通过则丢弃报文，且只有验签通过的报文，才进入后续的业务数据处理；

终端与业务云端存在双向交互，在本发明的android平台上基于native服务实现的签名验签方法中，支持双向数字签名与验签处理，可保证业务交互的安全，其具体的双向签名验签处理流程为：终端应用向云端发送业务请求时，基于业务数据、时间戳、随机数、业务key计算数字签名，将签名序列添加在请求中发送给云端；云端接收到请求后，解析时间戳、比较签名，只有校验通过的请求，才进入后续的业务数据处理，否则请求被丢弃，同时，在云端需要将业务回应数据发送给终端时，将基于业务数据、业务key的组合计算数字签名，再发送给终端；终端应用接收到回应报文后解析出业务数据、签名序列，调用终端验签接口，验签成功说明发送云端为合法平台，接收的数据合法，可以安全地使用，否则丢弃回应报文；

本发明的方法通过在android智能电视中实现核心native服务，用于封装各种加解密、hash算法、签名、验签处理；且终端应用与业务云端发送请求、获取应答时基于该native服务实现双向验签和关键数据的加密处理，从而保证端云业务数据交互的安全运营，实现防止伪设备网络攻击、重要数据篡改、关键数据泄露等安全风险。

进一步地，所述步骤a中进行基于业务数据及安全参数的签名时，具体流程如下：

s101.终端应用组装出要发送请求的业务数据并将业务数据按照键值升序排列后和时间戳、随机数组成字符串序列，然后转为统一的byte数组；

s102.终端应用基于appkey获取业务的加密secretkey，其中，所述appkey为网络传输中可见的明文，与终端应用为一一对应的关系；

s103.终端应用获取native服务，基于byte数组、加密secretkey作为输入参数，调用native服务的签名处理接口；

s104.native服务解密secretkey，然后组合时间戳、随机数、secretkey和业务数据，实施签名；

s105.终端应用从native服务获取返回签名状态、签名序列；

上述appkey具体为平台调用终端应用的id，appkey是与业务绑定，不同的业务在终端上是不同的应用来实现，终端应用与appkey是一一对应的，通过此参数可识别调用不同的调用者(业务)，且secretkey是从appkey上延伸出来的安全参数，用于参与签名与验签处理；同时，为了保证secretkey的使用安全，secretkey是基于加密保存，在签名/验签时再解密使用；

进一步地，所述步骤f中的验签处理具体包括以下步骤：

s201.终端应用从接收的回应报文中解析业务数据、签名序列并转为byte数组；

s202.终端应用基于appkey获取到安全参数：加密secretkey；

s203.终端应用获取native服务，基于byte数组、安全参数作为输入参数，调用native服务的验签接口；

s204.native服务解密所述加密secretkey，然后组合安全参数和业务数据，实施签名并输出签名序列；

s205.native服务将步骤s204得到的签名序列与所述步骤s201中的签名序列比较，一致则返回验签成功，否则返回验签失败。

进一步地，在终端上调用native服务的实现流程如下：

s301.终端系统启动时，native服务由init进程启动后台运行中；

s302.终端app应用层通过binder服务，获取服务实例；

s303.终端基于对应接口index序号，设置入参调用对应的接口；

s304.终端解析native服务返回的状态和输出结果；

实际中，为了适应多业务运营下终端电视上应用交互安全，每个参与云端交互的应用都需要支持签名与验签处理，因此需要提供通用的签名验签和加解密处理模块，本发明的技术方案基于android系统各版本平台上的兼容性、多应用调用接口的移植性，采用基于native层实现的服务来替代sdk软件包提供接口调用的方案，将核心算法由系统native层服务实现，具体有以下几点优点：

首先，不同android版本上兼容，不再受到不同版本上域名空间的限制，其次，native层服务移植或版本升级更加方便，不需要各上层应用逐个更新，最后，算法和密钥都在native层封装和实现，比应用层安全更有保障。

本发明与现有技术相比，具有以下的有益效果：

通过本发明的android平台上基于native服务实现的签名验签方法，在android智能设备的端云业务数据交互中，通过关键业务数据的加密处理保证了数据安全；同时，基于业务数据与安全参数组合的签名与验签处理，保证通信双方的身份识别和确认数据完整性；这些安全机制可有效防止数据篡改、重放攻击、以及业务接口被伪装和恶意利用等风险，保障了android智能电视上端云业务运营安全。

附图说明

图1是本发明的android平台上基于native服务实现的签名验签方法的流程示意图。

图2是本发明的一个实施例中终端基于业务数据和安全参数的签名流程示意图。

图3是本发明的一个实施例中终端基于业务数据和安全参数的验签流程示意图。

图4是本发明的一个实施例中android智能设备上应用调用native服务的实现流程示意图。

具体实施方式

下面结合本发明的实施例对本发明作进一步的阐述和说明。

实施例：

android智能电视上基于电视厂商云端服务器部署的运营性业务中存在频繁的数据交互，需要预防数据被窃取和恶意利用，以及基于交互报文的网络攻击，如防重放攻击(请求被截获并被多次重放)、防数据信息泄漏(如截获用户登录请求，截获到账号/密码等重要信息)等，可基于交互数据的数字签名和加密传输等方式来为业务运营保驾护航。因此，我们要在终端电视上为端云交互的应用提供一套高效安全的双向验签和加解密处理方案。

本实施例在android智能电视与云端服务器之间安全交互接口设计基础上，提出了native服务实现核心算法，与终端应用配合提供高效、安全的签名、验签、hash散列、加解密算法等接口的调用，为上层应用与云端交互时提供双向签名与验签、数据加密处理。

如图1所示，一种android平台上基于native服务实现的签名验签方法，具体包括以下步骤：

a.终端应用将业务数据及安全参数传给native服务实施签名，调用成功返回终端数字签名信息；其中，所述安全参数至少包含时间戳、随机数、secretkey；

b.终端发送携带安全参数和数字签名信息的业务请求给云端；

c.云端接收到请求报文后解析出业务数据，并基于安全sdk实现验签处理，若验签通过则向终端返回业务数据正常处理，否则，丢弃请求报文；

d.云端对通过验签的请求进行回应处理，对业务数据结合安全参数，调用安全sdk实现云端数字签名；

e.云端将携带数字签名的报文发送回终端；

f.终端应用解析回应报文，并基于native服务实现验签处理，验签不通过则丢弃报文，且只有验签通过的报文，才进入后续的业务数据处理。

为了进一步说明本技术方案，本实施例中，将对以下内容进行具体说明：

本方案中的安全参数的设计实现：

具体的，数字签名具有保护数据完整性作用，如果端云业务交互中只针对业务数据签名，仍然无法防止伪设备窃取利用数据实现的重放攻击，对此，本方案中设计了安全参数，由安全参数与业务数据组合体来实现数字签名，具有更高安全。

在本发明的技术方案中，其终端电视上安全参数的设计具体如下：

appkey：appkey是平台调用app应用的id，在网络传输中可见的明文，不同的业务在终端上是不同的应用来实现，appkey与业务绑定且终端应用与appkey是一一对应的，通过appkey参数可识别到不同的调用者(业务)，appkey与数字签名的安全参数secretkey有关。

secretkey：secretkey是从appkey上延伸出来的安全参数，参与签名与验签处理；为了保证secretkey的使用安全，secretkey基于加密保存，在签名/验签时再解密使用。

appkey与secretkey：

appkey是作为业务标志来设计的，在接口中明文传输，故签名验签处理时设计了加密secretkey。在业务管理服务器平台上负责每项端云交互业务中key的申请和维护。服务器为每项交互业务的终端应用和云端分配一对appkey和secretkey字符序列，然后将secretkey实施加密，将密文secretkey分配给终端应用。

终端应用基于自己的业务appkey获取密文secretkey，在请求发送前签名时，由native服务先将密文secretkey解密为明文secretkey，然后再用来组装数据计算消息摘要，获得签名序列，一起发送给云端。云端接收到请求后，解析出业务数据和签名，保持与终端一致的签名计算方式，得到新签名。

sign(签名)是接口上携带的数字签名，基于hex编码可视化。签名有两个使用途径：一是请求内携带的签名与之前请求报文的签名比较，甄别出重复请求，直接丢弃不处理；二是云端计算出的签名与报文内携带的签名比较，不同则认为数据被篡改或不完整，验签不通过，丢弃请求不处理。

nonce(随机数)：随机数可为数字签名增加安全保障，对于终端设备是唯一的。将该参数信息纳入签名数据中，有助于云端对终端请求的验签处理，随机数是由终端设备信息生成，如基于mac地址、sn号等生成，本实施例中是基于mac地址生成的随机数。

timestamp(时间戳)：即unix时间戳，是从时间服务器获取，终端与云端时间戳来源都是时间服务器，两者的时间在系统启动时就是维持同步状态，同时兼容一定时间差异，例如1分钟，故时间戳用于终端到云端方向上的签名与验签处理，不仅纳入签名处理，还作为评估终端请求是否有效的参数。

如果云端接收到请求时的时间戳与请求内携带的时间戳间隔在一定时间内，才认为是可能有效的请求，否则直接丢弃请求不处理。

终端电视签名的设计与实现：

具体的，终端电视的签名是由业务应用和统一native服务来协同完成的，跟业务相关的由应用层来完成，与业务无关的则由native服务来完成，如加解密和签名验签的具体实现，如图2所示，本实施例中的步骤a中终端基于业务数据和安全参数的签名流程如下：

s1.1终端应用准备数据：业务数据content、获取时间戳timestamp、产生随机数nonce，并将业务数据content按照升序排列后和时间戳、随机数组成字符串序列，然后转为统一的byte数组；

s1.2终端应用获取业务的加密secretkey：终端应用基于appkey获取到加密secretkey、随机数nonce、时间戳timestamp等这些安全参数；

s1.3终端应用获取native服务实例：基于byte数组、加密secretkey作为输入参数，调用native服务的签名接口；

s1.4native服务解密secretkey，然后组合安全参数和业务数据，实施签名；

s1.5终端应用获取签名返回状态、签名序列。若签名成功，则在后续步骤中将签名序列加入请求中发送出去。

终端电视验签的设计与实现：

终端电视验签云端回应报文处理，与反方向的验签稍有差异，主要体现在业务报文对目的设备的影响上。在云端到终端的签名验签过程中，时间戳和随机数则没有使用的意义。云端只将业务的加密secretkey，解密获取原始secretkey，基于该key与回应报文的业务数据组合为待签名数据，获取签名后一起发送给终端。具体的，如图3所示，本实施例中，步骤f中终端接收回应报文后的验签处理如下：

s2.1终端应用提取回应报文中的数据：业务数据content、签名序列并转为byte数组；

s2.2终端应用获取该业务的加密secretkey：终端应用基于appkey获取到加密secretkey；

s2.3终端应用获取native服务实例，基于业务数据content、签名序列、加密secretkey作为输入参数，调用native服务的验签接口；

s2.4native服务解密secretkey，然后组合解密的secretkey和业务数据，实施签名并输出签名序列；

s2.5native服务将步骤s2.4输出的签名序列与步骤s2.1提取的签名序列比较，一致则返回验签成功，否则返回验签失败并返回验签结果。

当验签成功后则继续后续的业务报文的解析处理；否则丢弃本次回应报文。

终端电视上应用调用native服务的实现：

为了适应多业务运营下终端电视上应用交互安全，每个参与云端交互的应用都需要支持签名与验签处理，因此需要提供通用的签名验签和加解密处理模块。从android系统各版本平台上的兼容性、多应用调用接口的移植性本实施例中采用系统中基于native层实现的服务，来替代sdk软件包提供接口调用的方案。将核心算法由系统native层服务实现，有以下几个好处：

1)不同android版本上兼容，不再受到不同版本上域名空间的限制；

2)native层服务移植或版本升级更加方便，不需要各上层应用逐个更新；

3)算法和密钥都在native层封装和实现，比应用层安全更有保障。

具体的，android智能终端电视上在native层实现服务，支持各种算法处理，为上层应用提供服务调用的接口，由两部分组成：一是服务端server的实现；二是在开机系统启动时运行该服务。

native服务运行在android系统的runtime层，由c/c++语言实现，其中跟系统框架的交互支持由c++实现，核心算法源码则是c源码库，提供了aes/tea等堆成加密算法、sha1/sha256等hash散列算法、rsa非对称算法等。源码工程实现后，在android平台上编译出可执行文件，即为native服务的server。

android系统启动时，在init启动脚本中增加service，设置该service为开机时后台启动运行、权限等属性。系统中还集成了c层客户端文件，便于验证集成在系统中的service运行状态，并提供service的版本查询、算法流程验证等功能。

具体的，如图4所示，本实施例中，android智能设备上应用调用native服务的实现流程如下：

s3.1系统启动时，native服务由init进程启动后台运行中；

s3.2app应用层通过binder服务，获取服务实例；

s3.3基于对应接口index序号，设置入参调用对应的接口；

s3.4解析服务返回的状态和输出结果。

其中，android平台上runtime层的native服务支持多个应用层进程调用，具有相互独立性，包括c实现的客户端，也包括应用app中的实例。

由上可知，本发明的android平台上基于native服务实现的签名验签方法解决的技术问题主要在于在android智能电视平台上支持多业务端云交互中双向验签，为多个业务应用提供高效、安全的签名、验签、数据加解密处理的调用，其主要用于在android智能电视中实现核心native服务，用于封装各种加解密、hash算法、签名、验签处理；终端应用与业务云端发送请求、获取应答时基于该native服务实现双向验签和关键数据的加密处理，保证端云业务数据交互的安全运营，防止伪设备网络攻击、重要数据篡改、关键数据泄露等安全风险。

可以理解的是，以上实施方式仅仅是为了说明本发明的原理而采用的示例性实施方式，然而本发明并不局限于此。对于本领域内的普通技术人员而言，在不脱离本发明的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本发明的保护范围。