一种身份认证方法和设备
本申请要求2015年09月14日递交的申请号为201510583968.6、发明名称为“一种身份认证方法和设备”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域,特别涉及一种身份认证方法和设备。
背景技术
可穿戴设备即直接穿在用户身上或是整合到用户的衣服或配件上的一种便携式设备,现主流的产品形态包括以手腕为支撑的watch类(包括手表和腕带等产品),以脚为支撑的shoes类(包括鞋、袜子或者将来的其他腿上佩戴产品),以头部为支撑的Glass类(包括眼镜、头盔、头带等),以及智能服装、书包、拐杖、配饰等各类非主流产品形态。
由于可穿戴设备本身的随身穿戴属性,很多业务都希望可以通过可穿戴设备来更多的参与到身份认证或者操作相应处理过程中,以此来实现与使用者更紧密的互动,并提高安全性。
因此,如何实现基于可穿戴设备的支付认证或者其他操作过程中的身份认证操作已成为计算机技术领域的研究重点之一。
其中,支付认证,是一种特殊的身份认证,指的是对用户正在进行的与资金流转相关的支付行为的合法性进行判断的一种操作行为,由于与资金相关,这样的身份认证尤其受到安全性、便捷性的挑战。
现有技术中传统的基于可穿戴设备的身份认证,尤其是支付认证操作过程的实现流程大致如下:
与可穿戴设备绑定的移动终端在接收到一个支付认证请求之后,是由移动终端来负责对这个支付认证请求的合法性进行认证的;并在认证通过、完成扣费之后,将相应的扣费成功信息发送给所述可穿戴设备;反之,将相应的扣费失败信息发送给所述可穿戴设备;由所述可穿戴设备对扣费结果进行显示。
申请人在实现本申请的过程中发现,上述传统的基于可穿戴设备的身份认证方法,尤其是支付认证方法至少存在如下的问题:
现有技术中,与对支付认证请求的合法性进行认证的相关计算都是在移动终端上实现的,可穿戴设备只负责显示扣费结果。
进一步的,由于相关计算在移动终端上实现时,用户的支付过程参与感弱、支付过程的安全性低,进而影响支付成功率。
因此,本领域技术人员亟待找到一种方法,能够增强用户在身份认证过程中的参与感、增强认证过程的安全性、并提高认证成功率。
发明内容
本申请实施例提供一种身份认证方法和设备,以实现增强用户的身份认证过程参与感、增强身份认证过程的安全性、并提高身份认证成功率,尤其是对于支付认证过程。
为了达到上述技术目的,本申请提供了一种身份认证方法,应用于包含预设标准接口的终端设备上,所述预设标准接口用于与专属类型的业务应用进行通信,具体包括:
所述终端设备通过所述预设标准接口接收所述专属类型的业务应用所对应的服务器发送的身份认证请求消息,其中,所述身份认证请求消息是所述服务器收到所述专属类型的业务应用的业务请求后,发送给所述终端设备的;
所述终端设备根据所述专属类型的业务应用的公钥验证所述身份认证请求消息的签名;
如果验证通过,所述终端设备在本地预先存储的业务认证信息中,获取所述身份认证请求消息所对应的账户的业务认证信息;
所述终端设备将获取到的业务认证信息携带在验证响应消息中,通过所述预设标准接口返回给所述服务器。
另外,本申请实施例还提供了一种身份认证方法,应用于专属类型的业务应用所对应的服务器上,所述服务器通过终端设备所包含的预设标准接口,与所述终端设备进行通信,所述方法具体包括:
所述服务器接收所述专属类型的业务应用的业务请求;
所述服务器通过所述终端设备所包含的预设标准接口,向所述终端设备发送身份认证请求消息;
当身份认证请求成功时,所述服务器接收到所述终端设备通过所述预设标准接口返回的携带业务认证信息的验证响应消息;
所述服务器根据所述业务认证消息,对所述业务请求进行处理。
另外,本申请实施例还提供了一种终端设备,具体包括:
预设标准接口,用于与专属类型的业务应用进行通信;
接收模块,用于通过所述预设标准接口接收所述专属类型的业务应用所对应的服务器发送的身份认证请求消息,其中,所述身份认证请求消息是所述服务器收到所述专属类型的业务应用的业务请求后,发送给所述终端设备的;
验证模块,用于根据所述专属类型的业务应用的公钥验证所述接收模块所接收到的身份认证请求消息的签名;
获取模块,用于在所述验证模块验证通过时,在所述终端设备预先存储的业务认证信息中,获取所述身份认证请求消息所对应的账户的业务认证信息;
反馈模块,用于将所述获取模块所获取到的业务认证信息携带在验证响应消息中,通过所述预设标准接口返回给所述服务器。
另外,本申请实施例还提供了一种服务器,与专属类型的业务应用相对应,具体包括:
发送模块,用于在接收到所述专属类型的业务应用的业务请求时,通过所述终端设备所包含的预设标准接口,向所述终端设备发送身份认证请求消息;
接收模块,用于当身份认证请求成功时,接收所述终端设备通过所述预设标准接口返回的携带业务认证信息的验证响应消息;
处理模块,用于根据所述接收模块所接收到的所述业务认证消息,对所述业务请求进行处理。
与现有技术相比,本申请实施例所提出的技术方案的有益技术效果包括:
本申请实施例公开了一种身份认证方法和设备,应用于由服务器和包含预设标准接口的终端设备所组成的系统中,该预设标准接口用于与专属类型的业务应用进行通信,通过应用本申请所提出的技术方案,在需要进行身份认证操作时,服务器可以通过预设标准接口向终端设备请求专属类型的业务应用的帐户的业务认证信息,而终端设备则可以通过相应的验证规则对此过程的安全性进行验证,只有在验证通过的情况下,才会将预先保存在本地的业务认证信息反馈给服务器进行后续处理,从而,通过与专属类型的业务应用相绑定的预设标准接口,以及终端设备自身的安全验证,实现身份认证过程安全性的保障,而与现在终端设备中保存的身份认证信息则加强了终端设备操作者在此过程中的参与感,在该终端设备具体为可穿戴设备的情况下,可以实现增强用户的身份认
证过程参与感、增强身份认证过程的安全性、并提高身份认证成功率,尤其是对于支付认证过程。
附图说明
为了更清楚地说明本申请的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例所提出的一种身份认证方法的流程示意图;
图2为本申请实施例所提出的一种身份认证方法中的绑定过程的流程示意图;
图3为本申请实施例所提出的一种身份认证方法中的认证过程的流程示意图;
图4为本申请实施例所提出的一种终端设备的结构示意图;
图5为本申请实施例所提出的一种服务器的结构示意图。
具体实施方式
正如本申请背景技术所陈述的,在现有技术中,对身份认证,尤其是支付认证请求进行合法性认证的相关计算处理都是在移动终端上实现的,而与之关联的可穿戴设备只负责显示处理结果,这样的操作过程导致了用户在身份认证,尤其是支付过程中的参与感弱、安全性低,进而影响业务成功率。
而本申请的发明人发现,相比于移动终端,通过可穿戴设备进行处理具有以下优点:
第一、更便于操作,对应的用户在相应处理过程中的参与感也将增强;
第二、对可穿戴设备进行操作的安全性更高,例如,更具私密性,不容易被偷窥等,对应的支付过程的安全性也将增强;
基于上述的两个优点,通过可穿戴设备进行处理能够提高支付过程的成功率。
基于以上的分析,为了解决上述的技术问题,本申请实施例公开了一种在可穿戴设备上实现的身份认证方法,当然,这样的方法也可以应用在其他类型的终端设备上,这样的变化并不会影响本申请的保护范围。
如图1所示,为本申请实施例一提供的一种身份认证方法的流程示意图,该方法应用于包含预设标准接口的终端设备上,所述预设标准接口用于与专属类型的业务应用进行通信,该方法具体包括:
步骤S101、所述终端设备通过所述预设标准接口接收所述专属类型的业务应用所对应的服务器发送的身份认证请求消息。
其中,所述身份认证请求消息是所述服务器收到所述专属类型的业务应用的业务请求后,发送给所述终端设备的。
在具体的应用场景中,这里所提及的专属类型的业务应用主要是指与预设标准接口相匹配的,在具体业务执行中需要进行身份认证操作的类型的业务应用,在其与一个预设标准接口相匹配(可以通过接口定义或者标准协议限定)后,只有类型相匹配的业务应用所触发的消息才会通过该预设标准接口实现通信传输,这样的限定可以有效的过滤其他类别业务应用的信息交互过程,从而避免其他信息对该专属类型的业务应用的信息交互过程的干扰,提高了相应的信息处理效率,而且,专属类型的限定,也可以有效的屏蔽其他伪造报文或信令通过该预设标准接口的传入或攻击,提高了身份认证过程的安全性。
需要说明的是,在后续处理中,终端设备与专属类型的业务应用的信息交互是通过预设标准接口来实现的,在后续对应的步骤中有对应的说明,在此不再赘述。
通过上述的预设标准接口的限制,其他业务应用所发送的消息不会通过该预设标准接口被终端设备接收到,自然也不会触发本实施例所提出的技术方案,从而,实现了身份认证过程中的信息过滤,不会受到其他消息的干扰,增强了身份认证过程的安全性。
步骤S102、所述终端设备根据所述专属类型的业务应用的公钥验证所述身份认证请求消息的签名。
如果验证通过,则认定该身份认证请求消息是合法的上述专属类型的业务应用所发送的消息,是安全的,可以继续执行步骤S103;
如果验证失败,则认定该身份认证请求消息并不是合法的上述专属类型的业务应用所发送的消息,所以,直接丢弃该身份认证请求消息。
步骤S103、所述终端设备在本地预先存储的业务认证信息中,获取所述身份认证请求消息所对应的账户的业务认证信息。
具体的,在本实施例中,在本步骤执行之前,终端设备在本地预先存储业务认证信息的操作过程,具体如下:
首先,所述终端设备通过所述预设标准接口接收所述专属类型的业务应用发送的一个账户的绑定注册请求消息。
然后,所述终端设备验证该绑定注册请求消息的合法性,即根据所述专属类型的业
务应用的公钥验证所述绑定注册请求消息的签名。
如果验证通过,所述终端设备获取所述绑定注册请求消息所携带的业务认证信息,并将所述业务认证信息与所述账户的身份识别信息对应存储在本地,用于后续的认证操作,其中身份识别信息用于表示该业务认证信息所归属的账户。
而如果验证失败,则认定该绑定注册请求消息并不是合法的上述专属类型的业务应用所发送的消息,是无效的,所以,直接丢弃该绑定注册请求消息。
最后,在上述的业务认证信息和身份识别信息保存完成后,所述终端设备根据自身的标识信息生成注册响应消息,并通过所述预设标准接口将所述注册响应消息返回给所述专属类型的业务应用。
其中,在具体的应用场景中,上述的注册响应消息的生成过程具体如下:
所述终端设备获取自身的唯一标识信息和设备model信息;
所述终端设备按照所述专属类型的业务应用所规定的数据格式组装所述唯一标识信息和设备model信息;
所述终端设备使用本地私钥对组装完成的信息进行签名,生成注册响应消息。
当然,考虑到账户使用者本身对于业务认证信息(例如支付密码,支付手势等)的变更,后续还可以通过以下流程可对当前存储的信息进行更新。
步骤A、所述终端设备通过所述预设标准接口接收所述专属类型的业务应用发送的一个账户的业务认证信息更新请求消息。
步骤B、所述终端设备根据所述专属类型的业务应用的公钥验证所述业务认证信息更新请求消息的签名。
如果验证失败,则认定该业务认证信息更新请求消息并不是合法的上述专属类型的业务应用所发送的消息,是无效的,所以,直接丢弃该业务认证信息更新请求消息。
如果验证通过,则执行步骤C。
步骤C、所述终端设备判断本地所存储的业务认证信息所对应的身份识别信息与所述业务认证信息更新请求消息所携带的身份识别信息是否一致。
如果一致,则确认终端设备中之前已经保存了相同账户的业务认证信息,与该业务认证信息更新请求消息相匹配,出发后续的步骤D操作。
相反,如果不一致,则确认终端设备中之前并没有保存相同账户的业务认证信息,与该业务认证信息更新请求消息无法匹配,没有被更新对象,后续如何处理可以根据实际需要进行确定。
步骤D、所述终端设备获取所述业务认证信息更新请求消息中携带的业务认证信息。
步骤E、所述终端设备判断获取的业务认证信息的版本信息是否高于当前本地存储的相对应的业务认证信息的版本信息。
通过本步骤,可以确定终端设备当前存储的业务认证信息是否需要进行更新。
如果判断结果为是,则表示本地业务认证信息已经不是最新版本,需要进行更新,所述终端设备用获取的业务认证信息替换当前存储的对应的业务认证信息。
如果判断结果为否,即获取的业务认证信息的版本信息等于或低于当前本地存储的相对应的业务认证信息的版本信息,表示本地业务认证信息无需进行更新,结束当前的更新操作。
步骤S104、所述终端设备将获取到的业务认证信息携带在验证响应消息中,通过所述预设标准接口返回给所述服务器。
在具体的应用场景中,出于安全考虑,本步骤中进行支付凭证信息返回的过程中,可以将业务认证信息进行加密,保存为响应数据包,服务器在接收到该响应数据包之后,通过解密获得业务认证信息,从而完成后续的业务处理操作。
在具体的应用场景中,本步骤完成之后,还可以包括相应的确认过程,具体说明如下:
所述终端设备通过所述预设标准接口接收所述专属类型的业务应用所对应的服务器发送的确认请求;
所述终端设备获取所述确认请求中包含的确认方式类型信息;
所述终端设备根据所述确认方式类型信息完成对应的确认操作。
具体的,在本实施例中,该确认请求中包含的确认方式类型信息可包括如下确认方式中的任意一种或任意组合:
文本确认、声音确认以及震动确认。
对应的,例如,文本确认可以为直接在终端设备上显示一行文字“您已成功支付”,“业务处理成功”等,当然,前提是终端设备上要有显示屏;声音确认可以为发出预设的“铃声”;震动确认可以为预设次数或连续一定时间的震动。
这样的确认操作主要是为了使用户能够准确的确认业务处理的结果,当然,也可以设置在业务处理成功的情况下无需进一步操作,这样的设置可以根据实际需要进行调整,不会影响本申请的保护范围。
上述说明过程描述了终端设备侧的方案实现过程,相对应的,本申请实施例同样提出了服务器侧的方案实现流程,该方法应用于专属类型的业务应用所对应的服务器上,所述服务器通过终端设备所包含的预设标准接口,与所述终端设备进行通信,所述方法具体包括:
首先,所述服务器接收所述专属类型的业务应用的业务请求。
然后,所述服务器通过所述终端设备所包含的预设标准接口,向所述终端设备发送身份认证请求消息。
当身份认证请求成功时,所述服务器接收到所述终端设备通过所述预设标准接口返回的携带业务认证信息的验证响应消息。
所述服务器根据所述业务认证消息,对所述业务请求进行处理。
在具体的应用场景中,所述服务器接收到所述专属类型的业务应用的业务请求之前,还包括业务认证信息的预存储过程:
所述服务器通过所述终端设备所包含的预设标准接口,向所述终端设备发送一个账户的绑定注册请求消息,所述绑定注册请求消息中携带所述账户的业务认证信息。
当注册绑定成功时,所述服务器接收到所述终端设备通过所述预设标准接口返回的注册响应消息,所述注册响应消息中携带所述终端设备的标识信息,所述服务器确认所述终端设备与所述账户绑定成功。
这样的预存储过程与前述的步骤S103中的终端设备在本地预先存储业务认证信息的操作过程相对应,在此不再具体说明。
进一步的,在所述服务器确认所述终端设备与所述账户绑定成功之后,还包括:
当所述帐户的业务认证信息需要更新时,所述服务器通过所述终端设备所包含的预设标准接口,向所述终端设备发送所述账户的业务认证信息更新请求消息,其中,所述业务认证信息更新请求消息中携带所述账户需要更新的业务认证信息。
本过程也与之前步骤S103中步骤A至步骤E的处理过程相对应,在此不再具体说明。
另一方面,在所述服务器根据所述业务认证消息,对所述业务请求进行处理之后,还可以包括相应的确认过程,具体说明如下:
当所述业务请求处理完成后,所述服务器通过所述终端设备所包含的预设标准接口,向所述终端设备发送携带了确认方式类型信息的确认请求,以使所述终端设备根据所述确认方式类型信息完成对应的确认操作。
确认请求发送之后,就与步骤S104中的后续确认过程相对应,在此不再具体说明。
在此需要说明的是,上述的各步骤中,所述终端设备通过所述预设标准接口所接收的所有消息中,至少包括消息自身的操作类型信息和签名信息;
其中,所述签名信息应与所述预设标准接口所对应的专属类型的业务应用相匹配,从而,可以通过该专属类型的业务应用的公钥进行验证,如果验证失败,自然也就可以确认当前消息并不是与该专属类型相匹配的,可以达到过滤无关消息,从而提高安全性的目的。
与现有技术相比,本申请实施例所提出的技术方案的有益技术效果包括:
本申请实施例公开了一种身份认证方法和设备,应用于由服务器和包含预设标准接口的终端设备所组成的系统中,该预设标准接口用于与专属类型的业务应用进行通信,通过应用本申请所提出的技术方案,在需要进行身份认证操作时,服务器可以通过预设标准接口向终端设备请求专属类型的业务应用的帐户的业务认证信息,而终端设备则可以通过相应的验证规则对此过程的安全性进行验证,只有在验证通过的情况下,才会将预先保存在本地的业务认证信息反馈给服务器进行后续处理,从而,通过与专属类型的业务应用相绑定的预设标准接口,以及终端设备自身的安全验证,实现身份认证过程安全性的保障,而与现在终端设备中保存的身份认证信息则加强了终端设备操作者在此过程中的参与感,在该终端设备具体为可穿戴设备的情况下,可以实现增强用户的身份认证过程参与感、增强身份认证过程的安全性、并提高身份认证成功率,尤其是对于支付认证过程。
下面将结合本申请中的附图,对本申请中的技术方案进行清楚、完整的描述,显然,所描述的实施例是本申请的一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
考虑到可穿戴设备本身的随身性和对安全性的保证,以及支付类业务对于安全性的高标准要求,本申请后续实施例中采用可穿戴设备实现支付认证的过程为例进行技术方案的说明,相应的,上述的终端设备即后续的可穿戴设备,而上述的专属类型的业务应用即后续的支付类业务应用,而相应的专属类型即为支付。
需要说明的是,这只是一种优选的实施例,其他类型的终端设备以及其他类型业务的身份认证过程都可以应用于本申请的技术方案中,这样的变化并不会影响本申请的保护范围。
首先,对本申请实施例所提出的技术方案的应用场景介绍如下:
(1)可穿戴设备,一种同时兼具可穿戴、支付两项功能的设备,例如,智能手表、智能徽章、智能眼镜等,其自身具有支付功能,或者安装了具有支付功能的应用,从而,可以对关联的账户进行相应的支付操作,该设备自身与支付类应用的服务器,以及安装了该支付类应用的可支付终端之间通过预设标准接口进行通信,该预设标准接口可以是符合支付协议的标准接口。
(2)可支付终端,例如智能手机、智能平板电脑(Pad),自身具有支付功能,或者安装了具有支付功能的应用,与可穿戴设备关联了相同的用户账户,出于用户需要或者设置,需要通过可穿戴设备进行支付操作的确认,该设备自身与前述的可穿戴设备,以及支付服务器之间同样通过预设标准接口进行通信,该预设标准接口可以是符合支付协议的标准接口。
(3)支付服务器,具有支付处理和验证能力的服务器,在验证通过后最终执行支付操作。
基于上述的业务架构,其中的预设标准接口可以根据相应的协议进行配置,针对于本申请实施例所提出的具体示例,可以采用例如内容的协议进行接口配置:
采用ATT格式配置协议标准,并通过UUID标识一个唯一的专属类型属性。
针对具体的身份认证过程,可以将该预设标准接口的协议配置为由1个service及4个characteristic组成,具体的:
Service的UUID:0x0001000(确定所对应的业务应用的专属类型);
Characteristic:有4个characteristic,分别是注册、验证、更新秘钥、确认(震动)。相应的characteristic的UUID分别是:0x0000 0011,0x0000 0012,0x0000 0013,0x0000 0014,从而,可以标识具体接口的功能差异。
当然,这样的设置只是一种具体的示例,在实际应用中,可以不进行上述功能的差异化区分,而是根据消息自身的类型标识触发不同的处理,当然,也可以根据业务内容的不同而设置更多的characteristic,这样的变化并不会影响本申请的保护范围。
基于上述的系统场景,并进一步考虑到可穿戴设备计算及存储能力的限制,以及耗电量的要求,所以,可以尽量让可穿戴设备负责更少的处理操作。
在本申请所提出的技术方案中,可穿戴设备存储了关键的验证信息(即前述的业务认证信息),只有在身份验证合法的情况下,向支付服务器反馈该验证信息,使支付操作得以顺利完成。
下面,按照时间顺序,依次对各阶段的操作流程进行说明。
一、绑定阶段。
在本阶段中,需要建立可穿戴设备与具体账户之间的绑定关系,并且在可穿戴设备中同步存储所绑定的账户的支付凭证信息(即前述的业务认证信息的一种特例,后续说明中也存在类似设定,不再一一陈述)。
具体的,如图2所示,为本申请实施例所提出的一种身份认证方法中的绑定过程的流程示意图,在本实施例中,可穿戴设备根据预设的注册策略在本地存储业务认证信息,从而与相应的专属类型的业务应用账户完成绑定,具体的流程如下:
步骤S201、可穿戴设备通过预设标准接口接收注册请求。
在具体的应用场景中,如果需要基于网络侧的账户身份验证,可以通过支付服务器来进行触发上述的注册过程,而如果基于本地识别信息(如本地密钥协商)匹配,则可以是可支付终端上的支付类业务应用直接向可穿戴设备发起注册过程,但无论是哪种发起方式,由于所处理的业务类型都是支付类业务,所以,都需要通过预设标准接口来完成,这样可以屏蔽掉其他类型业务消息的告饶,而且,增加本类型业务操作的安全性。
考虑到本绑定过程的最终目的在于验证信息(即前述业务认证信息)的同步存储,所以,如果是可支付终端上的支付类业务应用直接向可穿戴设备发起注册过程,则需要可支付终端上的支付类业务应用直接提供相应的验证信息。
无论采用上述的哪种处理方案,考虑到上述的绑定是基于同一支付账户的绑定,所以,在后续过程中忽略掉具体触发形式的差异,直接以支付账户所在的支付类业务应用为触发主体进行相应的绑定操作。
步骤S202、可穿戴设备按照预设的数据格式标准解析注册请求,获取其中所携带的信息。
支付类业务应用向可穿戴设备的预设标准接口发起注册请求(例如,对于可支付终端上的支付类应用直接发起的绑定过程,可以直接通过蓝牙传输,而对于经由支付服务器发起的绑定过程,则可以是通过支付服务器向可穿戴设备的预设标准接口来传输的),可穿戴设备在接收到数据后按照预先设定的数据传输格式进行反序列化(反序列化操作也即解析操作)处理,得到注册请求中所携带的验证信息。
需要进一步指出的是,注册请求以及后文中其他发送给预设标准接口的消息中为了完成相应的合法性验证操作,需要携带验证类型信息和具体的签名信息,这是必须携带的关键验证信息,在此进行具体说明后,其他消息与此类似,不再一一重复描述。
A、验证类型信息:
目前可穿戴设备有两种验证方案,一种是安全性较强的,在加密和验证签名采用的是RSA,另一种是对于编程性不高的,安全性较低的方案,采用对称加密。
B、签名信息:按照一定的签名算法所生成的签名信息,后文中的其他消息也与此类似,都可以通过自身需要单独携带的信息按照一定的签名算法生成签名信息。
在具体的应用场景中,签名算法类型主要有sha256,rsawithsha256。
在具体的应用场景中,除了上述的关键验证信息,该注册请求中可包括以下几部分内容,当然,在能够实现注册绑定操作的前提下,注册请求中所携带的信息类型并不会影响本申请的保护范围:
(1)报文相关信息,用于标识该注册请求自身的信息,包括:签名后数据的长度、签名后的数据;
(2)身份相关信息,用于验证注册请求的合法性,包括:支付业务签名信息(即前述的身份识别信息)、该支付业务签名信息的长度信息、Challenge(挑战)信息、该Challenge信息的长度信息;
(3)算法相关信息,用于解析或生成签名,包括:签名算法类型信息、该签名算法的长度信息;
另外,需要说明的是,在本实施例中,上述签名算法可为安全散列算法SHA(Secure Hash Algorithm)256或者非对称散列算法RSA with SHA 256;在具体的环境中,也可为其他签名算法,在此不在阐述。
(4)支付凭证相关信息,用于在后续过程中对支付操作进行认证,包括:由可支付终端生成的用于支持所述支付服务器完成扣费操作的共享密钥(即支付凭证信息)、该共享密钥的长度信息。
步骤S203、可穿戴设备验证注册请求的合法性。
在具体的应用场景中,当前述的信息反序列化操作成功后,可穿戴设备根据预设的验证信息进行验证操作,具体的,可以根据其内置的支付业务公钥对进行步骤S202中反序列化操作后的签名相关信息进行验证操作。
如果验证成功,则执行步骤S204,而如果验证不通过,则可穿戴设备判定该注册请求是无效或非法的,所以,直接丢弃该注册请求。
步骤S204、可穿戴设备获取并存储支付凭证信息和身份识别信息。
可穿戴设备根据其内置的的私钥对步骤S202中进行反序列化操作后的支付凭证相
关信息进行解密操作,获取支付凭证信息。
可穿戴设备获取步骤S202中进行反序列化操作后的设备标识相关信息,
可穿戴设备将获取到的支付凭证信息和身份识别信息进行本地存储,例如存储在本地ROM(Read-Only Memory,只读存储器)中。
至此,在可穿戴设备侧,对于绑定关系的保存已经完成,在后续的操作中,需要将绑定情况反馈给对端的可支付终端上的支付类业务应用,在双侧都对绑定关系进行成功处理后,绑定操作才真正得以完成。
步骤S205、可穿戴设备根据预设的反馈规则,将自身的身份识别信息等绑定相关信息进行反馈。
可穿戴设备根据自身的唯一ID(身份识别信息),设备model(模式)等信息,按照预设的反馈信息组装规则,生成相应的注册响应消息,发送给注册请求的发送端,即如果是可支付终端直接发起的注册请求,则直接反馈给该可支付终端,如果是通过网络侧的支付服务器发起的注册请求,则反馈给支付服务器,再由支付服务器进行后续的绑定确认反馈。
需要说明的是,上述的加密/解密方式都是基于安全考虑而进行的保障性工作,在能够保证安全性的基础上,是否采用上述的加密/解密方式,以及是否采用其他的安全防护措施,都不会影响本申请的保护范围。
在具体的应用场景中,除了前述的关键验证信息,该注册响应消息中可包括以下几部分内容,当然,在能够实现注册绑定操作的前提下,注册响应消息中所携带的信息类型并不会影响本申请的保护范围:
(1)报文相关信息,用于标识该注册请求自身的信息,包括:签名后数据的长度、签名后的数据;
(2)身份相关信息,用于验证注册请求的合法性,包括:支付业务签名信息(即前述的身份识别信息)、该支付业务签名信息的长度信息、Challenge(挑战)信息、该Challenge信息的长度信息;
(3)算法相关信息,用于解析或生成签名,包括:签名算法类型信息、该签名算法的长度信息;
另外,需要说明的是,在本实施例中,上述签名算法可为SHA 256或者RSA with SHA256;在具体的环境中,也可为其他签名算法,在此不在阐述。
(4)可穿戴设备相关信息,用于使注册发起端能够获取注册成功的可穿戴设备的信
息,包括:可穿戴设备根据自身的唯一ID信息、唯一ID信息的长度信息,设备model信息、设备model信息的长度信息。
通过上述的处理,可穿戴设备中成功的保存了于自身绑定的支付类业务应用账户的支付认证信息和身份识别信息,但是,考虑到用户本身对于支付凭证信息(例如支付密码,支付手势等)的变更,后续还可以通过以下流程可对当前存储的信息进行更新,具体的更新操作可以参考上述的注册过程,只是在确定更新支付认证信息之前,需要增加身份识别信息的比对过程(确认是同一个用户的更新操作),以及支付认证信息的版本比较过程(只有更高版本的支付认证信息才会被保存),在此不再赘述。
二、认证阶段。
在本阶段中,可穿戴设备进行了本申请所提出技术方案的核心处理,即可穿戴设备对支付请求过程进行认证操作,只有认证成功的操作,才允许被继续执行。
具体的,如图3所示,为本申请实施例所提出的一种身份认证方法中的认证过程的流程示意图,在本实施例中,可穿戴设备根据预设的认证策略对可支付终端发送的支付认证请求进行合法性认证操作,具体的流程如下:
步骤S301:可穿戴设备通过预设标准接口接收通过支付服务器发送的支付认证请求。
在具体的应用场景中,支付操作一般是在可支付终端发起的,其向支付服务器发送支付请求,请求进行一个支付操作,而支付服务器在接收到该支付请求后,触发支付认证过程,向可穿戴设备发送支付认证请求。
该支付认证请求可以通过前述的可穿戴设备的预设标准接口接收。
步骤S302、可穿戴设备按照预设的数据格式标准解析支付认证请求,获取其中所携带的信息。
当支付类业务应用接收到用户发起的支付进程时,支付类业务应用向可穿戴设备的预设标准接口发起支付认证请求,可穿戴设备在接收到数据后按照预先设定的数据传输格式进行反序列化(反序列化操作也即解析操作)处理,得到支付认证请求中所携带的验证信息。
在具体的应用场景中,除了前述的关键验证信息,该支付认证请求中可包括以下几部分内容,当然,在能够实现支付认证操作的前提下,支付认证请求中所携带的信息类型并不会影响本申请的保护范围:
(1)报文相关信息,用于标识该支付认证请求自身的信息,包括:签名后数据的长
度、签名后的数据;
(2)身份相关信息,用于验证支付认证请求与可穿戴设备所绑定账户的匹配,包括:支付业务签名信息(即前述的身份识别信息)、该支付业务签名信息的长度信息、Challenge(挑战)信息、该Challenge信息的长度信息;
(3)算法相关信息,用于解析或生成签名,包括:签名算法类型信息、该签名算法的长度信息;
另外,需要说明的是,在本实施例中,上述签名算法可为SHA 256或者rsa with sha256;在具体的环境中,也可为其他签名算法,在此不在阐述。
步骤S303、可穿戴设备对该支付认证请求所对应的账户与本地保存的支付凭证信息所对应的账户之间的绑定关系进行验证。
在具体的应用场景中,可穿戴设备需要根据反序列化得到的信息与本地信息进行比对,判断该支付认证请求所对应的支付类业务应用的账户,是否为自身所绑定的支付类业务应用的账户。
在具体的应用场景中,可以是根据消息中所携带的身份识别信息与本地保存的支付凭证信息所对应的身份识别信息进行匹配的结果来进行验证,。
如果验证成功,则执行步骤S304,如果验证失败,则认定该支付认证请求对应的是与自身无关的其他账户,所以,直接丢弃该支付认证请求。
步骤S304、可穿戴设备根据存储的可支付终端的支付凭证信息生成身份密钥。
使用在之前的绑定过程中存储在ROM的支付凭证信息生成身份密钥。
在具体的应用场景中,可以使用支付类业务应用的公钥加密该身份密钥,并按照认证输出参数序列化数据,从而生成可以反馈的反馈数据(即前述的响应数据包)。
在具体的应用场景中,除了前述的关键验证信息,该反馈数据中可包括以下几部分内容,当然,在能够实现身份密钥的反馈操作的前提下,反馈数据中所携带的信息类型并不会影响本申请的保护范围:
(1)报文相关信息,用于标识该反馈数据自身的信息,包括:签名后数据的长度、签名后的数据;
(2)身份相关信息,用于验证反馈数据的合法性,包括:支付业务签名信息(即前述的身份识别信息)、该支付业务签名信息的长度信息、Challenge信息、该Challenge信息的长度信息;
(3)算法相关信息,用于解析或生成签名,包括:签名算法类型信息、该签名算法
的长度信息;
另外,需要说明的是,在本实施例中,上述签名算法可为SHA 256或者RSA with SHA256;在具体的环境中,也可为其他签名算法,在此不在阐述。
(4)支付凭证相关信息,用于使验证发起端能够获取支付凭证信息,包括:使用绑定时永久化在本地ROM保存的支付凭证信息加密后的身份串的长度,身份串数据。
步骤S205、可穿戴设备根据预设的反馈规则,发送反馈数据,以使支付服务器完成扣费操作。
支付服务器在接收到该反馈数据之后,通过解密获得支付凭证信息,从而完成后续的扣费操作。
需要说明的是,上述的加密/解密方式都是基于安全考虑而进行的保障性工作,在能够保证安全性的基础上,是否采用上述的加密/解密方式,以及是否采用其他的安全防护措施,都不会影响本申请的保护范围。
三、确认阶段。
在本阶段中,可穿戴设备根据支付服务器反馈的支付进程的操作结果,向用户进行确认响应。
所述可穿戴设备通过预设标准接口接收所述支付服务器发送来的确认请求;
所述可穿戴设备获取所述确认请求中包含的确认方式类型信息;
所述可穿戴设备根据所述确认方式类型信息完成对应的确认操作。
具体的,在本实施例中,该确认请求中包含的确认方式类型信息可包括如下确认方式中的任意一种或任意组合:
文本确认、声音确认以及震动确认。
对应的,例如,文本确认可以为直接在可穿戴制度设备上显示一行文字“您已成功支付”,当然,前提是可穿戴设备上要有显示屏;声音确认可以为发出预设的“铃声”;震动确认可以为预设次数或连续一定时间的震动。
这样的确认操作主要是为了使用户能够准确的确认支付结果,当然,也可以设置支付成功的情况下无需进一步操作,这样的设置可以根据实际需要进行调整,不会影响本申请的保护范围。
与现有技术相比,本申请实施例所提出的技术方案的有益技术效果包括:
本申请实施例公开了一种身份认证方法和设备,应用于由服务器和包含预设标准接口的终端设备所组成的系统中,该预设标准接口用于与专属类型的业务应用进行通信,
通过应用本申请所提出的技术方案,在需要进行身份认证操作时,服务器可以通过预设标准接口向终端设备请求专属类型的业务应用的帐户的业务认证信息,而终端设备则可以通过相应的验证规则对此过程的安全性进行验证,只有在验证通过的情况下,才会将预先保存在本地的业务认证信息反馈给服务器进行后续处理,从而,通过与专属类型的业务应用相绑定的预设标准接口,以及终端设备自身的安全验证,实现身份认证过程安全性的保障,而与现在终端设备中保存的身份认证信息则加强了终端设备操作者在此过程中的参与感,在该终端设备具体为可穿戴设备的情况下,可以实现增强用户的身份认证过程参与感、增强身份认证过程的安全性、并提高身份认证成功率,尤其是对于支付认证过程。
为更清楚地说明本申请前述实施例提供的方案,基于与上述方法同样的发明构思,本申请实施例还提出了一种终端设备,其结构示意图如图4所示,具体包括:
预设标准接口41,用于与专属类型的业务应用进行通信;
接收模块42,用于通过所述预设标准接口41接收所述专属类型的业务应用所对应的服务器发送的身份认证请求消息,其中,所述身份认证请求消息是所述服务器收到所述专属类型的业务应用的业务请求后,发送给所述终端设备的;
验证模块43,用于根据所述专属类型的业务应用的公钥验证所述接收模块42所接收到的身份认证请求消息的签名;
获取模块44,用于在所述验证模块43验证通过时,在所述终端设备预先存储的业务认证信息中,获取所述身份认证请求消息所对应的账户的业务认证信息;
反馈模块45,用于将所述获取模块44所获取到的业务认证信息携带在验证响应消息中,通过所述预设标准接口41返回给所述服务器。
在具体的应用场景中,
所述接收模块42,还用于通过所述预设标准接口41接收所述专属类型的业务应用发送的一个账户的绑定注册请求消息;
所述验证模块43,还用于根据所述专属类型的业务应用的公钥验证所述接收模块42所接收到的绑定注册请求消息的签名;
所述获取模块44,还用于在所述验证模块43验证通过时,获取所述绑定注册请求消息所携带的业务认证信息,并将所述业务认证信息与所述账户的身份识别信息对应存储在所述终端设备中;
所述反馈模块45,还用于根据所述终端设备的标识信息生成注册响应消息,并通过
所述预设标准接口41将所述注册响应消息返回给所述专属类型的业务应用。
进一步的,该终端设备还包括更新模块46:
所述接收模块42,还用于通过所述预设标准接口41接收所述专属类型的业务应用发送的一个账户的业务认证信息更新请求消息;
所述验证模块43,还用于根据所述专属类型的业务应用的公钥验证所述接收模块42所接收到的业务认证信息更新请求消息的签名,并在验证通过时,判断所述终端设备所存储的业务认证信息所对应的身份识别信息与所述业务认证信息更新请求消息所携带的身份识别信息是否一致;
所述获取模块44,还用于在所述验证模块43的判断结果为是时,获取所述业务认证信息更新请求消息中携带的业务认证信息;
所述更新模块46,用于判断所述获取模块44所获取的业务认证信息的版本信息是否高于当前所述终端设备本地存储的相对应的业务认证信息的版本信息,如果判断结果为是,则用所述获取模块44所获取的业务认证信息替换所述终端设备当前存储的对应的业务认证信息。
在具体的应用场景中,
所述接收模块42,还用于通过所述预设标准接口41接收所述专属类型的业务应用所对应的服务器发送的确认请求;
所述获取模块44,还用于获取所述确认请求中包含的确认方式类型信息,以使所述终端设备根据所述确认方式类型信息完成对应的确认操作。
另一方面,本申请实施例还提出了一种服务器,其结构示意图如图5所示,该服务器为专属类型的业务应用提供业务服务,具体包括:
发送模块51,用于在接收到所述专属类型的业务应用的业务请求时,通过所述终端设备所包含的预设标准接口,向所述终端设备发送身份认证请求消息;
接收模块52,用于当身份认证请求成功时,接收所述终端设备通过所述预设标准接口返回的携带业务认证信息的验证响应消息;
处理模块53,用于根据所述接收模块52所接收到的所述业务认证消息,对所述业务请求进行处理。
在具体的应用场景中,
所述发送模块51,还用于通过所述终端设备所包含的预设标准接口,向所述终端设备发送一个账户的绑定注册请求消息,所述绑定注册请求消息中携带所述账户的业务认
证信息;
所述接收模块52,还用于当注册绑定成功时,接收所述终端设备通过所述预设标准接口返回的注册响应消息,所述注册响应消息中携带所述终端设备的标识信息,并确认所述终端设备与所述账户绑定成功。
具体的,所述发送模块51,还用于:
在所述帐户的业务认证信息需要更新时,通过所述终端设备所包含的预设标准接口,向所述终端设备发送所述账户的业务认证信息更新请求消息,其中,所述业务认证信息更新请求消息中携带所述账户需要更新的业务认证信息;
和/或,当所述处理模块53对所述业务请求处理完成后,通过所述终端设备所包含的预设标准接口,向所述终端设备发送携带了确认方式类型信息的确认请求,以使所述终端设备根据所述确认方式类型信息完成对应的确认操作。
与现有技术相比,本申请实施例所提出的技术方案至少具有以下优点:
本申请实施例公开了一种身份认证方法和设备,应用于由服务器和包含预设标准接口的终端设备所组成的系统中,该预设标准接口用于与专属类型的业务应用进行通信,通过应用本申请所提出的技术方案,在需要进行身份认证操作时,服务器可以通过预设标准接口向终端设备请求专属类型的业务应用的帐户的业务认证信息,而终端设备则可以通过相应的验证规则对此过程的安全性进行验证,只有在验证通过的情况下,才会将预先保存在本地的业务认证信息反馈给服务器进行后续处理,从而,通过与专属类型的业务应用相绑定的预设标准接口,以及终端设备自身的安全验证,实现身份认证过程安全性的保障,而与现在终端设备中保存的身份认证信息则加强了终端设备操作者在此过程中的参与感,在该终端设备具体为可穿戴设备的情况下,可以实现增强用户的身份认证过程参与感、增强身份认证过程的安全性、并提高身份认证成功率,尤其是对于支付认证过程。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明实施例可以通过硬件实现,也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解,本发明实施例的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或网络侧设备等)执行本发明实施例各个实施场景所述的方法。
本领域技术人员可以理解附图只是一个优选实施场景的示意图,附图中的模块或流
程并不一定是实施本发明实施例所必须的。
本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中,也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述,不代表实施场景的优劣。
以上公开的仅为本发明实施例的几个具体实施场景,但是,本发明实施例并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明实施例的业务限制范围。