一种在协同签名系统中增强访问控制安全性的方法与流程

文档序号:31223280发布日期:2022-08-23 17:39阅读:75来源:国知局
一种在协同签名系统中增强访问控制安全性的方法与流程

1.本发明属于信息安全技术领域,具体为一种在协同签名系统中增强访问控制安全性的方法。


背景技术:

2.随着移动互联网业务的飞速发展,用户已经习惯使用手机来处理各种安全业务,比如通过手机应用进行支付、身份认证、签署电子合同等。传统的基于se的安全方案因为需要额外的硬件资源,移动终端用户使用起来不方便、用户体验不好,部署和采购成本高。纯软件实现的安全方案严重依赖移动终端操作系统的安全性:如果操作系统被攻击,存储用户密钥的文件可能泄露或被篡改,密钥生成和密码运算过程在内存中也面临攻击威胁。
3.协同签名系统是一种客户端+服务端的安全解决方案,其客户端不依赖硬件密码芯片、用软件实现密码运算和数字证书应用等安全功能;其服务端具有高等级的安全环境和安全设备。协同签名系统在满足移动终端用户的身份认证、业务数据完整性、抗抵赖等安全需求的同时,还具有部署成本低、用户学习成本低、使用简单便捷、安全性高等显著优势。
4.在协同签名系统中,生成用户密钥对时,由客户端、服务端各自生成和保管用户私钥分量,且互相不知道对方持有的分量。使用用户私钥做数字签名、数据加解密时,也是由客户端、服务端依次用自己持有的私钥分量进行密码运算,客户端、服务端之间通过交换计算过程的中间参数,最终得到计算结果。在密钥生成、密钥使用阶段从不会出现完整的用户私钥,可以有效的保护用户密钥安全。
5.对协同签名系统进行威胁分析时,按攻击者的能力,破坏行为大致可分为三类:客户端静态分析、客户端动态分析、服务端攻击,具体见下表1。
6.表1协同签名系统受到的破坏行为分类
7.8.还可以考虑不同攻击结果造成的破坏性,下列攻击结果在威胁程度上依次递增:
9.a)能控制用户手机完成签名、解密的本地计算,但被服务端拒绝;
10.b)能获得客户端私钥分量的明文,可在任意设备上完成签名、解密的本地计算,但被服务端拒绝;
11.c)能使服务端响应请求,能得到签名、解密结果;
12.d)能获得客户端私钥分量的明文,及服务端私钥分量的明文,完全掌握用户私钥。
13.协同签名系统的安全性在于:当攻击者只具有上述一类能力时,不能破坏整个系统的安全性;即使攻击者能完全控制客户端,服务端还可以通过停用对应用户的服务端私钥分量,使攻击者不能仅通过客户端私钥分量完成密码计算,及时制止风险行为。
14.如果服务端的访问控制设计为仅依赖客户端提供的信息,那么当客户端被攻击者完全控制时,服务端的访问控制也会失效;在攻击被发现之前,攻击者可以随意通过被控制的客户端向服务端发出业务请求并通过访问控制检查,使服务端执行请求并返回响应,达到攻击目的。
15.通常,协同签名系统服务端对客户端的访问控制策略基于以下安全需求:
16.a)对用户的鉴别:合法用户才能生成密钥,只有密钥的所有者可以使用该密钥;
17.b)对客户端应用的鉴别:服务端只响应合法的应用的请求;
18.c)对客户端设备的鉴别:请求生成密钥的设备与该密钥绑定,将来也只允许该设备访问此密钥。
19.因此,客户端发给服务端的业务请求中,通常包含表2中的鉴别信息。协同签名系统的服务端收到来自客户端的业务请求时,会先验证表2中的鉴别信息,确认请求的合法性后,再执行请求的业务。
20.表2鉴别信息
21.鉴别信息示例用户的鉴别用户id、用户密码、用户pin客户端应用的鉴别应用id、应用签名、应用证书、secretkey客户端设备的鉴别设备软硬件信息、设备指纹、设备证书
22.上述鉴别信息的获取方式和处理者见表3。
23.表3鉴别信息的获取方式和处理者
24.鉴别信息获取方式处理者用户的鉴别用户在客户端应用中输入客户端设备客户端应用的鉴别客户端应用提供客户端设备客户端设备的鉴别客户端应用在客户端设备上采集客户端设备
25.可见,上述鉴别信息虽然具有多因素的特征,但都源自客户端设备,依赖客户端设备具有可信的运行环境和数据输入输出接口。考虑到协同签名系统的服务端的软硬件环境的安全性通常远高于客户端设备环境的安全性,而服务端对客户端业务请求的访问控制,全部鉴别数据都源自客户端提供的信息,实质上降低了系统的整体安全性。即攻击者只需对安全性较低的客户端实施攻击,即可控制安全性较高的服务端,执行期望的业务功能。在攻击行为被发现之前,攻击者可以用较低的成本突破原本安全级别较高的设施。服务端对客户端的访问控制成了系统安全的短板。


技术实现要素:

26.为解决现有技术存在的缺陷,本发明的目的在于提供一种在协同签名系统中增强访问控制安全性的方法,通过该方法能够显著增强访问控制的安全性,从而提升协同签名系统的整体安全性。
27.为达到以上目的,本发明采用的一种技术方案是:
28.一种在协同签名系统中增强访问控制安全性的方法,所述协同签名系统包括协同签名客户端和协同签名服务端,所述协同签名系统服务于业务系统,所述业务系统包括业务授权服务和运行在所述协同签名客户端上的业务应用;
29.所述方法包括业务预约阶段和业务调用阶段,业务预约阶段包括以下步骤:
30.s11、业务应用获取协同签名客户端的唯一标识;
31.s12、所述业务应用向业务授权服务发送业务预约请求;
32.s13、所述业务授权服务根据业务系统的既有规则验证业务请求的合法性;
33.s14、验证通过后,所述业务授权服务向协同签名服务端发送业务预约消息;
34.s15、所述协同签名服务端记录所述业务预约消息;
35.业务调用阶段包括以下步骤:
36.s21、所述业务应用调用所述协同签名客户端执行业务功能;
37.s22、所述协同签名客户端执行本地计算后,向所述协同签名服务端发起业务请求;
38.s23、所述协同签名服务端在已记录的业务预约消息中查找与当前业务请求相匹配的记录,如果未找到匹配的业务预约消息,丢弃当前业务请求,不做处理;
39.s24、如果找到匹配的业务预约消息,将所述业务预约消息记录的状态标记为已核销;
40.s25、所述协同签名服务端执行业务请求中的操作,并向所述协同签名客户端返回应答消息;
41.s26、所述协同签名客户端接收所述协同签名服务端的应答消息,完成本地计算后向所述业务应用返回调用结果。
42.进一步,如上所述的在协同签名系统中增强访问控制安全性的方法,所述协同签名服务端和所述业务授权服务处于同一内部网络或其他互相信任的网络域中。
43.进一步,如上所述的在协同签名系统中增强访问控制安全性的方法,所述协同签名服务端包括内部网络输入接口和外部网络输入接口,所述内部网络输入接口用于接收所述业务授权服务的业务预约请求;所述外部网络输入接口用于接收所述协同签名客户端的业务请求。
44.进一步,如上所述的在协同签名系统中增强访问控制安全性的方法,步骤s12中所述业务应用向业务授权服务发送的预约请求至少包括协同签名客户端唯一标识、业务功能和预约有效期。
45.进一步,如上所述的在协同签名系统中增强访问控制安全性的方法,步骤s13中所述既有规则是指所述业务应用与所述业务系统之间的既定协议。
46.进一步,如上所述的在协同签名系统中增强访问控制安全性的方法,步骤s14中所述业务授权服务向所述协同签名服务端发送的业务预约消息至少包括协同签名客户端唯
一标识、业务功能和预约有效期。
47.进一步,如上所述的在协同签名系统中增强访问控制安全性的方法,步骤s14中所述业务授权服务向所述协同签名服务端发送的业务预约消息还包括对用户的鉴别数据、对客户端应用的鉴别数据、对客户端设备的鉴别数据。
48.进一步,如上所述的在协同签名系统中增强访问控制安全性的方法,步骤s22中所述协同签名客户端向所述协同签名服务端发起的业务请求中包括客户端唯一标识、业务功能和计算中间参数。
49.进一步,如上所述的在协同签名系统中增强访问控制安全性的方法,步骤s23中遵循的匹配规则至少包括:相同的客户端标识、相同的业务功能、有效期未过期和预约记录状态未核销;只有满足全部匹配规则,才执行下步操作。
50.进一步,如上所述的在协同签名系统中增强访问控制安全性的方法,步骤s24中将所述预约消息记录的状态标记为已核销后,还执行以下操作:
51.检查当前业务请求中的多因子鉴别数据和已记录的预约消息中的数据是否一致,所述多因子鉴别数据包括对用户的鉴别数据、对客户端应用的鉴别数据、对客户端设备的鉴别数据;如果检查不通过,丢弃当前业务请求,不做处理。
52.采用本发明所述的在协同签名系统中增强访问控制安全性的方法,具有以下显著的技术效果:
53.1、增加了访问控制决策数据的来源:既有外部网络的客户端,又有内部网络中的业务系统;
54.2、增加了访问控制决策数据的多因素数量:除了现有技术中的用户信息、应用信息、客户端设备信息,又增加了业务系统既有的验证因素;
55.3、对用户无感,不增加用户学习成本和操作步骤。
附图说明
56.图1是本发明实施例中提供的一种在协同签名系统中增强访问控制安全性的方法流程图;
57.图2是本发明实施例中提供的一种在协同签名系统中增强访问控制安全性的方法业务功能调用过程示意图。
具体实施方式
58.下面结合具体的实施例与说明书附图对本发明进行进一步的描述。
59.本发明提供的一种在协同签名系统中增强访问控制安全性的方法,应用的协同签名系统包括协同签名客户端和协同签名服务端,协同签名系统服务于业务系统,业务系统中包括业务应用和业务授权服务,业务应用是一种安装在协同签名客户端上的app,用于调用协同签名客户端;协同签名服务端和业务授权服务逻辑上处于同一内部网络或其他相互信任的网络域中。
60.协同签名服务端具有两个输入接口:一是内部网络中的输入接口,接收业务授权服务的业务预约请求;二是外部网络中的输入接口,接收协同签名客户端的业务请求。服务端执行对客户端请求的访问控制时,既检查来自内部网络的预约信息记录,又检查来自外
部网络的业务请求;访问控制决策既考虑了业务系统既有的验证规则,又考虑了协同签名系统内部的验证规则。此时,攻击者除了要攻击协同签名客户端,还面临业务系统验证和内部网络边界的挑战,大大增加了攻击难度和成本;访问控制的有效性得以保证,系统的整体安全性显著提升。
61.图1示出了本发明实施例中提供的一种在协同签名系统中增强访问控制安全性的方法流程图,图2示出了业务功能调用过程示意图,该方法首先由业务应用发起协同签名业务功能调用,如生成密钥对、私钥签名、私钥解密等,每次调用过程都分为两个阶段:业务预约阶段和业务调用阶段。
62.业务预约阶段包括以下步骤:
63.s11、业务应用获取协同签名客户端的唯一标识;
64.s12、业务应用向业务授权服务发送预约请求;
65.业务应用向业务授权服务发送的预约请求至少包括协同签名客户端唯一标识、业务功能(如生成、签名、解密等)和预约有效期(如60s);还可以包括对用户的鉴别数据、对客户端应用的鉴别数据和对客户端设备的鉴别数据等其他鉴别信息。
66.s13、业务授权服务根据业务系统的既有规则验证业务请求的合法性;
67.业务系统的既有规则是指业务应用与业务系统之间的协议,如账户验证、人脸识别、业务规则风控等,是部署协同签名系统之前的既有策略。
68.s14、验证通过后,业务授权服务通过内部网络向协同签名服务端发送业务预约消息;
69.业务授权服务向协同签名服务端发送的业务预约消息至少包括协同签名客户端唯一标识、业务功能和预约有效期;还可以包括对用户的鉴别数据、对客户端应用的鉴别数据、对客户端设备的鉴别数据等其他鉴别信息。
70.s15、协同签名服务端记录业务预约消息。
71.至此,完成业务预约,开始业务调用。业务调用阶段包括以下步骤:
72.s21、业务应用调用协同签名客户端执行业务功能,如生成密钥对、私钥签名、私钥解密等;
73.s22、协同签名客户端执行本地计算后,向协同签名服务端发起业务请求;
74.协同签名客户端向协同签名服务端发起的业务请求中包含有客户端唯一标识、业务功能、计算中间参数等信息。
75.s23、协同签名服务端在已记录的预约消息中查找与当前业务请求相匹配的记录,如果未找到匹配的预约消息,丢弃当前业务请求,不做处理;
76.匹配规则至少包括:相同的客户端标识;相同的业务功能;有效期未过期;预约记录状态未核销。需满足全部匹配规则,才执行下步操作,否则丢弃当前业务请求,不做处理。
77.s24、如果找到匹配的预约消息,将该预约消息记录的状态标记为已核销;
78.每条业务预约记录只能使用一次,使用后要核销。将该预约消息记录的状态标记为已核销后,如果业务预约时已包含了对用户、对应用、对设备的多因子鉴别数据,此处还应对比业务请求中的多因子鉴别数据和已记录的预约消息中的数据是否一致,如果检查不通过,丢弃当前业务请求,不做处理。
79.s25、如果通过检查,协同签名服务端执行业务请求中的操作,并向协同签名客户
端返回应答消息;
80.s26、协同签名客户端接收协同签名服务端的应答消息,完成本地计算后向业务应用返回调用结果。
81.本发明提供的一种在协同签名系统中增强访问控制安全性的方法,通过在协同签名系统的“客户端-服务端”二元架构上,引入“业务授权方”角色,服务端对客户端的访问控制,不仅依赖客户端请求中提供的多因素鉴别数据,还依赖业务授权方提供的业务授权凭据。“业务授权方”的引入,使访问控制的判断依据不再只由客户端提供,可显著增强访问控制的安全性,从而提升协同签名系统的整体安全性。
82.上述实施例只是对本发明的举例说明,本发明也可以以其它的特定方式或其它的特定形式实施,而不偏离本发明的要旨或本质特征。因此,描述的实施方式从任何方面来看均应视为说明性而非限定性的。本发明的范围应由附加的权利要求说明,任何与权利要求的意图和范围等效的变化也应包含在本发明的范围内。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1