具体实施方式
为了更清楚地说明本说明书实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地,下面描述中的附图仅仅是本说明书的一些示例或实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图将本说明书应用于其它类似情景。除非从语言环境中显而易见或另做说明,图中相同标号代表相同结构或操作。
应当理解,本文使用的“系统”、“装置”、“单元”和/或“模块”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而,如果其他词语可实现相同的目的,则可通过其他表达来替换所述词语。
如本说明书和权利要求书中所示,除非上下文明确提示例外情形,“一”、“一个”、“一种”和/或“该”等词并非特指单数,也可包括复数。一般说来,术语“包括”与“包含”仅提示包括已明确标识的步骤和元素,而这些步骤和元素不构成一个排它性的罗列,方法或者设备也可能包含其它的步骤或元素。
本说明书中使用了流程图用来说明根据本说明书的实施例的系统所执行的操作。应当理解的是,前面或后面操作不一定按照顺序来精确地执行。相反,可以按照倒序或同时处理各个步骤。同时,也可以将其他操作添加到这些过程中,或从这些过程移除某一步或数步操作。
在一些应用场景中,业务方会把其产生的业务数据发送给第三方,例如,合作方、资方,以使业务数据产生更多的价值。例如,在物流业务场景中,物流订单或物流账单等物流数据可以反应物流业务方的运营情况,其除了可以供查询以外,还可以用来证明经营情况,作为一种资源产生金融价值,例如可以提供给资方从而进行融资。具体的,货物所有方可以委托物流承运平台将其货物从A地运送至B地,并支付物流费用。货物所有方可以向物流承运平台提交物流订单,物流订单可以具有唯一的标识用于分别不同的物流业务。随着物流业务的推进,该订单下会产生账单、发票等资金凭证。可以理解,一个订单可以对应一个或多个账单,每笔账单又可以对应一张或多张发票。为了便于描述,在本说明书后文中继续沿用该示例,应当理解,上述基于物流数据进行融资的场景仅作为示例,不应理解为对本说明书实施例应用场景的限制。
区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链的分布式、去中心化的特性可以有效地保护其链上的数据不被篡改和伪造,因此,区块链被广泛应用于各种应用场景,例如,金融业务场景、物流业务场景。
资方接收到数据的真实性关系到资金的安全,为了保证业务发送给资方的数据是真实、未经篡改的,在一些实施例中,可以将物流信息统一上传至区块链上,当业务方需要进行融资时,由资方从区块链上获取所需的数据或由区块链将特定数据推送给资方。但在场景中存在多个业务方以及数据流转中间环节较多的情况下,如何确定业务请求是由正确有效的业务方发出,成为有待解决的问题。
在一些实施例中,采用密钥进行验签,以确定业务方的身份是否正确,具体的,业务方利用自身持有的密钥(如私钥)对融资数据(如融资请求和/或物流数据)进行加密,银行持有与业务方密钥对应的密钥(如公钥),对从区块链上获取的融资数据进行验签或解密,从而确认业务方是正确有效的。但出于信息安全角度考虑,不同业务方之间使用的密钥是不同的,因此资方处会持有所有业务方相应的密钥,如场景中存在1000个业务方,业务方采用私钥进行签名,此时资方需要保存和维护1000组业务方的公钥,导致资方系统负担增加,并且泄密的可能性也增加。
针对上述不足,本说明书的一些实施例提出了一种基于区块链的融资事务中的身份验证方法,其在上传至区块链的数据中增加了一个或多个身份验证参数,资方可以通过身份验证参数验证业务方的身份,从而避免维护较多的密钥并保证了安全性。以下通过对附图的描述阐述本说明书披露的技术方案。
图1是根据本说明书一些实施例所示的区块链的融资事务中的身份验证的示例性交互流程图。
如图1所示,在应用场景中可以包括服务端110、第一区块链120、跨链设备130、第二区块链140、资方150和可信设备160。
在一些实施例中,服务端110可以接收请求方的业务数据并将业务数据存证到第一区块链120。如在物流融资事务中,其用于获取请求方的各种信息并根据需要进行核验、加密或上传等。在一些实施例中,服务端110可以属于数字物流系统。在一些实施例中,服务端110可以是带有数据获取、存储、计算、分析和/或发送功能的设备,如服务器。服务端110可以发送/接收数据,例如,服务端110可以将物流数据发送至第一区块链120,并获取第一区块链120返回的数据链上地址。在一些实施例中,服务端110可以是本地的或远程的。在一些实施例中,服务端110还可以在一个云平台上实现。仅作为示例,所述云平台可以包括私有云、公共云、混合云、社区云、分布云、云之间、多重云等或上述举例的任意组合。在一些实施例中,服务端110可以是链下的处理设备,其与第一区块链具有网络连接;或者可以是第一区块链120的节点之一。
在区块链中,区块链节点可以接收上传(或广播)至链的交易,调用相应的智能合约以完成交易的执行,交易以及交易执行的结果被写入区块保存到区块链数据中。
共识机制是区块链系统正常运行的必要组件,用于保证各节点保存的区块链数据维持一致。多个节点可以通过运行共识协议,对接收(对应代码的输入)、产生(对应代码的输出或中间结果)的数据和/或执行的操作达成一致,参与共识的节点可称为共识节点。例如,对于新区块涉及的多个交易,各共识节点可以通过运行共识协议对所述多个交易的执行顺序达成一致。又如,接收到验证交易的多个共识节点可以通过运行共识协议,对待存储数据的验证结果达成一致。
区块链数据(也可称为链上数据)可包括通过共识的区块数据和状态数据(也可称为全局状态或世界状态),区块链数据的写入也被叫作上链。其中,区块数据包括持续生成且按时序链接的区块,各共识节点可通过运行共识协议将新区块上链。共识通过意味着每个共识节点可将相同的新区块写入区块数据。仅作为示例,在一些实施例中,共识通过的条件包括超过预设比例(如2/3)的共识节点同意将新区块上链。状态数据可包括关联于各账户的状态变量,例如,个人、组织控制的外部账户的余额,又如,合约账户的合约状态。
值得说明的是,区块链具有公开透明的特性,因此任一节点可以获得区块链网络中广播的交易,如果将业务方(或请求方)数据以明文形式放入交易(如存证交易)中,可能存在泄密风险。有鉴于此,在一些实施例中,可以将物流数据以密文形式上传区块链,经授权的数据使用方可以使用密钥(如对称密钥或数据来源方公钥或自身私钥)对从链上获取的相应数据解密。
联盟链(Alliance chain)只针对某个特定群体的成员和有限的第三方,其内部指定多个预选节点为记账人,每个块的生成由所有的预选节点共同决定(或进行共识),其他接入节点可以参与交易,但不过问记账过程,可以通过该区块链开放的API进行限定查询。在一些实施例中,联盟链中的共识也可以由链上全部节点参与。
第一区块链120和第二区块链140可以是针对某些特定群体的成员和有限的第三方开放的联盟链。示例性的,在一些实施例中,第一区块链120和第二区块链140可以属于不同业务范围的联盟链,第一区块链120属于物流业务领域,第二区块链140属于金融业务领域。在一些实施例中,第一区块链120又可称为物流链,第二区块链140又可称为融资链。相应的,请求方,也可称为业务方(如物流承运平台)可以采集与物流业务相关的物联网数据(如物流订单、物流账单等)并发送给服务端110,通过服务端110存入第一区块链120中,资方150即为能够向请求方提供融资资金的资方150,如银行。通过第一区块链120和第二区块链140传业务相关的信息,为资方150的业务风控提供准确依据。
在一些实施例中,跨链设备130可以通过跨链技术在第一区块链120和第二区块链140之间传输数据和/或信息的设备,如服务器、虚拟机或区块链。在一些实施例中,跨链设备130可以将第一区块链120上的部分或所有信息跨链传输至第二区块链140,在一些实施例中,还可以通过跨链设备130对第一区块链120上的数据进行一定程度上的处理后,再传输至第二区块链140上。
本说明书的一些实施例还提供了一种基于区块链的融资事务中的身份验证方法,在一些实施例中,该方法中的一个或多个步骤可以由应用场景中的一方或多方执行,该方法的流程200包括以下步骤:
步骤210,通过服务端110接收请求方的融资请求并发送至第一区块链120,所述融资请求包括请求方信息以及抵押资产标识;其中,所述请求方信息至少包括一个或多个身份验证参数。在一些实施例中,步骤210可以由服务端110执行。
在一些实施例中,当某主体需要进行融资时,其可以作为请求方发出融资请求,服务端110接收该融资请求并发送至第一区块链120。示例性的,当融资事务为物流场景融资事务时,请求方为物流承运平台,其持有货物所有方在物流运输过程中的订单信息、账单信息和发票信息等。物流承运平台可以通过上述物流运输信息来证明其经营情况从而获得资方150的融资。
融资请求包括请求方信息以及抵押资产标识,在一些实施例中,融资请求还可以包括其他信息,如请求方银行账号、物流运输订单以及订单对应的货物清单等。在一些实施例中,所述请求方信息至少包括一个或多个身份验证参数,身份验证参数可以用于资方150验证请求方的身份,具体生成和进行验证的方法将在后文图3和图4中详细说明。
在一些实施例中,抵押资产可以认为是能够作为融资债权担保的财产或其证明信息,如在物流过程中产生的(电子)账单或(电子)发票信息等,相应的,抵押资产标识可以是能够唯一标识上述账单或发票信息的账单号或发票号等。在一些实施例中,抵押资产标识还可以是抵押资产上传第一区块链120后得到的在第一区块链120上的哈希值或链上地址等形式。在一些实施例中,抵押资产标识可以是账单号或发票号,服务端110可以将其转换为链上标识,如链上哈希或链上地址,再将所述请求方信息和抵押资产链上标识作为融资请求发送给第一区块链。可以理解,服务端110预先存储有抵押资产标识与抵押资产链上标识的映射关系。关于映射关系的建立过程可以参见图2的相关描述。
在一些实施例中,服务端110发送所述融资请求至第一区块链120前还需要进行核验等操作。例如,融资请求中还可以包括请求方的数字签名,服务端110可以基于请求方的公钥验证融资请求中的数字签名。又例如,服务端110可以基于抵押资产标识中的账单号确定其对应的订单号,进而可以核验融资请求中的发票号与账单号是否产生于同一订单。
在一些实施例中,服务端110可以作为第一区块链120的节点或用户端,融资请求可以由服务端获取并打包成交易(如查询或跨链交易)上传至所述第一区块链120。
步骤220,通过所述第一区块链120获取抵押资产链上数据,并生成融资请求跨链数据;其中,所述融资请求跨链数据包括请求方信息以及所述抵押资产链上数据。在一些实施例中,步骤220可以由第一区块链120执行。
包含融资请求的交易(如查询或跨链交易)上传至所述第一区块链120之后,该交易在第一区块链120中广播、共识和执行,从而第一区块链120基于融资请求中的抵押资产链上标识从区块链数据中获得抵押资产链上数据。作为示例,抵押资产链上数据可以是电子账单或电子发票等数据,或者其他资产凭证,其由业务方(或称为请求方,如物流承运平台)预先存入第一区块链中。关于抵押资产链上数据的存证过程可以参见图2的相关说明。
需要说明的是,由于共识机制保证了区块链节点的行为一致,因此在区块链中节点的行为可以等同于区块链行为或操作。
在一些实施例中,步骤220可以进一步包括以下步骤:
步骤222,基于所述请求方信息以及所述抵押资产链上数据生成以第一格式封装的融资请求跨链数据,并写入数据区块。
在一些实施例中,以第一格式封装的融资请求跨链数据可以理解成为了将数据从第一区块链120传输至第二区块链140,供跨链设备130拉取数据所进行的格式封装,在一些实施例中,第一格式封装的方式包括但不仅限于数据打包和加密等。封装后生成的以第一格式封装的融资请求跨链数据再次写入数据区块中,供跨链设备130获取,在一些实施例中,以第一格式封装的融资请求跨链数据中还可以包括跨链标识。需要说明的是,在一些实施例中,根据跨链设备130的不同,上述第一格式封装的方式也可以不同,在本说明书中不做限制。
步骤230,通过跨链设备130从第一区块链120获取所述融资请求跨链数据,并将其发送到第二区块链140,以便一个或多个资方150从所述第二区块链140中获取所述融资请求跨链数据,进而将其中的一个或多个身份验证参数发送到可信设备160,通过可信设备160中的验证程序对所述一个或多个身份验证参数进行验证得到请求方身份验证结果。
跨链设备130可以通过跨链技术将待跨链数据从第一区块链120传输至第二区块链140,同时,对于数据接收方(即此处的第二区块链140)而言,待跨链数据在传输过程中的每一个步骤都是经过验证可信的,其可以通过验证结果、数字签名等信息,反向追溯来源和处理过程的证明,实现了数据可信、可验证、可证明的数据传输。在一些实施例中,跨链设备130可以是能够执行跨链智能合约的设备或能够获取第一区块链120上数据和向第二区块链140上传数据的服务器。
在一些实施例中,跨链设备130从第一区块链120获取所述融资请求跨链数据,具体可以是通过跨链设备130监听第一区块链120中的区块,在发现带有跨链标识的融资请求跨链数据时,将其从所在区块提取出来并发送至第二区块链140。在一些其他实施例中,还可以是第一区块链120生成以第一格式封装的融资请求跨链数据后,通过触发跨链智能合约或发送跨链指令或推送跨链消息等方式,通知跨链设备130有新的跨链请求,之后跨链设备130从相应的数据区块中获取所述融资请求跨链数据将其发送至第二区块链140。在一些实施例中,跨链设备130可以作为第二区块链140的用户端,将融资请求跨链数据打包成交易(如存证交易)上传至所述第二区块链140。
在一些实施例中,出于不同区块链对数据的封装格式或加解密协议不同,跨链设备可以对融资请求跨链数据进行协议转换后再将其发送到第二区块链140。在一些实施例中,步骤230可以进一步包括以下步骤:
步骤232,从第一区块链120中获取数据区块并解析得到以第一格式封装的融资请求跨链数据。
在一些实施例中,跨链设备130可以按照第一格式封装协议从第一区块链120获取的融资请求跨链数据中提取出请求方信息以及抵押资产链上数据。第一格式封装协议规定了数据包中不同字段的属性或者含义,以便解析。在一些实施例中,出于信息安全的考虑,抵押资产链上数据在第一区块链中以密文形式存储,具体的,可以是服务端110对抵押资产链上数据进行加密后写入第一区块链。考虑到第二区块链采用的加解密算法与第一区块链不同,步骤230还可以包括步骤234,在两条区块链使用相同加解密算法或者抵押资产链上数据以明文形式存储时,步骤234可以省略。
步骤234,将所述融资请求跨链数据中的抵押资产链上数据解密。
在一些实施例中,跨链设备可以基于第一区块链的加解密算法对抵押资产链上数据进行解密以获得其明文。
步骤236,基于所述请求方信息以及解密后的抵押资产链上数据生成以第二格式封装的融资请求跨链数据。
与第一格式封装相似,在一些实施例中,第二格式封装的方式包括但不仅限于数据打包和加密等。第二格式封装可以理解成为了将数据从第一区块链120传输至第二区块链140,供第二区块链140落块所进行的格式封装。在一些实施例中,跨链设备130还可以基于第二区块链的加解密算法对解密后的抵押资产链上数据加密后再将其以第二格式封装到融资请求跨链数据中。
需要说明的是,在一些实施例中,步骤234解密后的抵押资产链上数据中可能存在资方150所不需要的数据,如订单信息对应的订单号或无效账单等,因此在步骤236中,在生成以第二格式封装的融资请求跨链数据前,可以基于预设的业务逻辑对抵押资产链上数据进行筛选。在一些实施例中,预设的业务逻辑可以根据实际场景进行配置,在此不做限制。
步骤238,将以第二格式封装的融资请求跨链数据发送到第二区块链140。
步骤240,通过第二区块链接收并存储所述融资请求跨链数据。
在一些实施例中,跨链设备130可以将融资请求跨链数据打包成存证交易,并提交给第二区块链140。之后,交易在第二区块链140中广播、共识和执行,如第二区块链140可以将融资请求跨链数据写入区块链数据中。在一些实施例中,第二区块链140会对融资请求跨链数据进行核验后再写入区块链数据。
将融资请求跨链数据发送到第二区块链140后,资方150可以从所述第二区块链140中获取所述融资请求跨链数据。在一些实施例中,资方150可以是第二区块链的用户或者成员节点,其可以主动监听区块以获取写入第二区块链中的融资请求跨链数据,或者第二区块链的节点可以向资方推送融资请求消息,之后资方可以从相应的区块中获取其关注的融资请求的跨链数据。资方150可以对其收到的融资请求跨链数据进行核验,以确定是否接收请求方的融资请求。其中,核验可以包括请求方身份验证,以确定请求的发起者是否是正确有效或者是目标业务方。例如,资方150将融资请求跨链数据中的一个或多个身份验证参数发送到可信设备160,通过可信设备160中的验证程序对所述一个或多个身份验证参数进行验证得到请求方身份验证结果。
在一些实施例中,抵押资产链上数据为密文形式,资方150在获取所述融资请求跨链数据后,需对其进行解密,得到请求方信息和融资所需的抵押资产标识。在一些实施例中,抵押资产链上数据可以是服务端110或跨链设备130加密得到,因此,资方150只需持有与服务端110或跨链设备130加密所使用的密钥相对应的密钥即可进行解密,而无需存储于所有请求方的密钥。在一些实施例中,可以采用非对称加密的方式对数据进行加密,具体的,服务端110或跨链设备130通过资方150的公钥对抵押资产链上数据进行加密,资方150通过其持有的私钥对抵押资产链上数据进行解密。由此可以看出,在一些实施例中,资方150只需要持有一个私钥即可,大大减轻了密钥维护成本。
在一些实施例中,解密得到的请求方信息包括一个或多个身份验证参数,资方150通过可信设备160中的验证程序对所述一个或多个身份验证参数请求方进行身份验证的具体流程,可以参见后文中图4~图5相关描述。
应当注意的是,上述有关步骤210~240的描述仅仅是为了示例和说明,而不限定本说明书的适用范围。对于本领域技术人员来说,在本说明书的指导下可以对步骤210~240进行各种修正和改变。然而,这些修正和改变仍在本说明书的范围之内。
图2是根据本说明书一些实施例所示的业务方、服务端和第一区块链的示例性交互流程图。
图2中还包括业务方170,在一些实施例中,业务方170与请求方可以是同一主体在不同阶段的不同身份,例如,业务方后续可以成为请求方,如在物流融资事务中,业务方170可以是物流承运平台。
在一些实施例中,服务端110可以执行图2中步骤201~205以接收业务方170的物流数据并发送至第一区块链120进行存证,进而生成抵押资产链上数据,其包括:
步骤201,接收业务方170发送的物流数据。
在一些实施例中,融资场景中会不断产生可以用于融资的抵押资产,如在物流运输过程中,会不断产生账单和发票信息等。具体的,当货物所有方需要进行货物运输时,可以向物流承运平台发起货运请求,进而生成一笔物流订单,该订单具有唯一的标识,如订单号。随着该笔物流业务的进行,陆续产生账单,每一笔账单具有唯一的标识,如账单号。账单记录着款项的发生时间,收款方以及付款方。当付款方向收款方支付后,会进一步产生发票信息。每一张发票具有唯一的标识,如发票编号。账单与发票信息可以反映业务方的运营情况。为了确保物流数据的真实可靠,或者为了便于管理,业务方170可以通过服务端110定期将物流运输中产生的物流数据(如账单号、发票号、电子账单或电子发票等凭证)上传至第一区块链120上。
步骤202,对物流数据进行核验。
在一些实施例中,服务端110可以基于订单内所包括的账单和发票之间的勾稽关系,验证所上传信息的真实性和一致性。
可选的,在一些实施例中,还可以包括步骤2021,为了增加数据的安全性,避免隐私数据泄露,服务端110可以将物流数据进行加密。
步骤203,将物流数据上传至第一区块链120。
核验通过后,服务端110将物流数据上传第一区块链120。具体的,服务端110可以将物流数据打包成存证交易,并发送给第一区块链120。第一区块链120对交易进行验证、共识后,将存证交易中的物流数据写入第一区块链120。
步骤204,接收第一区块链返回的存证结果。
当第一区块链120将物流数据存入区块链数据后,可以向服务端返回存证成功的提示以及该物流数据的链上标识(如链上哈希值或链上地址)。在一些实施例中,每一笔账单以及每一张发票分别对应一个链上标识。服务端110可以在本地维护一张映射表,该映射表记录每一笔账单或发票的标识(如账单号或发票号)对应的链上标识。可以理解,每一笔账单信息或发票信息都包括其所述的订单编号,因此,即使物流数据中的账单信息或发票信息非同时写入区块链,也可以基于其所属的订单编号确定各账单信息或发票信息的关联。
步骤205,向业务方返回存证结果。
在一些实施例中,服务端110可以将指示存证成功与否的提示返回给业务方170,或者连同物流数据的链上标识一并返回给业务方170。
物流数据存入区块链数据后,其真实性得到了认证,其进一步可以衍生为数据资产,如可以成为融资抵押资产,相应的,链上存储的物流数据可以成为抵押资产链上数据。业务方170可以在后续融资环节中作为请求方发起融资请求。
图3是根据本说明书一些实施例所示的一种身份验证方法的示例性流程图。
在一些实施例中,可以由需要验证身份信息的一方(或称为部署方)按照其自身制定(无权限方不能获知)的预设算法或预设条件生成一个或多个参数。在一些实施例中,预设条件或预设关系可以包括但不仅限于关系运算、逻辑运算、算术运算等。示例性的,在一些实施例中,参数可以包括两个,分别为seed和token,将预设条件定义为:
t(seed)*h(seed)*token=w(seed)*v(seed);(1)
其中:
t(seed)=seed+seed*seed
h(seed)=seed2+3*seed
w(seed)=seed3+seed
v(seed)=9*seed;
由上述公式可以看出,在一些实施例中,当seed=2时,可以将式(1)写成:
6*10*token=10*18;(2)
对式(2)求解可以得到token=3。即可以将seed和token的值作为所述一个或多个参数。
不难理解,这些参数中不包括部署方的任何其他信息,当接收到这些参数的一方通过部署方编写的验证程序证明这些参数确实满足预设算法或预设条件时,则可认为这些参数由部署方发送,进而可以验证参数发送方的身份信息。因此,在一些实施例中,所述一个或多个参数又称为身份验证参数。所述一个或多个参数可以由部署方设置在某服务请求中并请求某项服务,以便提供服务的一方能够验证该请求是由部署方发起。
本说明书的一些实施例提供了一种身份验证方法,在一些实施例中,该方法的一个或多个步骤由具有可信执行环境的设备,如可信设备160,执行。
可信执行环境可以提供与不可信环境隔离的安全计算环境,在可信执行环境中执行的计算或运行的程序可以被认为是可信的。可信执行环境可以部署在处理设备中。可信执行环境可以包括Software Guard Extensions、Secure Encrypted Virtualization或Trust Zone等。
在一些实施例中,身份验证方法的流程300可以包括:
步骤310,接收部署方发送的验证程序,并将其部署在所述可信执行环境中。在一些实施例中,步骤310可以由程序部署模块510执行。
在一些实施例中,部署方可以是需要被验证身份信息的一方,如图2中融资场景中的业务方170,其需要向资方证明其身份的正确性。
在一些实施例中,验证程序可以是部署方基于自定义的预设条件或预设算法,如公式(1),编写的应用程序。当核验请求方持有该身份验证参数时,将其输入至该验证程序中,该验证程序可以判断身份验证参数是否满足预设条件或预设算法,当满足则可以判断这些身份验证参数来自部署方,并且除此之外核验请求方无法获知其他任何信息。
在一些实施例中,所述可信执行环境内具有虚拟机。虚拟机是指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。在一些实施例中,虚拟机可以包括但不限于以太坊虚拟机(Embedded Virtural Machine,EVM)、EOS虚拟机(Web Assembly,WASM)、比原链虚拟机(Bottos Virtural Machine,BVM)和小蚁虚拟机(Antshares Virtural Machine,Antshares VM)等。虚拟机可以用于运行智能合约。在一些实施例中,部署方可以基于预设算法或条件编写智能合约,并编译获得字节码后部署到可信执行环境中,可信执行环境可以执行智能合约以通过身份验证参数进行身份验证。
步骤320,接收核验请求方发送的身份验证请求;所述身份验证请求至少包括一个或多个身份验证参数。在一些实施例中,步骤320可以由验证请求接收模块520执行。
在一些实施例中,当可信执行环境中部署有多个验证程序时,为了执行与目标部署方对应的验证程序以进行身份验证,核验请求方发送的身份验证请求还可以包括其他信息,如验证程序名等。在一些实施例中,核验请求方可以预先存储有正确有效的目标业务方的验证程序名,并在身份验证请求中携带该验证程序名。
步骤330,执行所述验证程序,以判断所述一个或多个身份验证参数是否满足预设条件或预设关系,进而获得指示所述一个或多个身份验证参数是否来自所述部署方的身份验证结果。在一些实施例中,步骤330可以由身份验证执行模块530执行。
继续采用上述示例,当验证程序接收核验请求方发送的身份验证请求中身份验证参数为2和3时,可以证明公式(1)的等式成立,则可以认为验证参数由部署方,如目标业务方,生成,身份验证通过;当执行验证程序后身份验证参数无法满足预设条件或预设关系、身份验证参数数量有误、身份验证参数字符形式有误等情况下,可以认为该身份验证参数不是由部署方生成的,可以理解,此时身份验证不通过。
步骤340,将所述身份验证结果返回给核验请求方。在一些实施例中,步骤340可以由验证结果返回模块540执行。
在一些实施例中,将身份验证结果返回给核验请求方以供核验请求方进一步处理,如在核验请求方为资方时,可以基于该身份验证结果拒绝融资请求方的融资申请。
在一些实施例中,图1中的可信设备160中具有可信执行环境,可以在该可信执行环境内可以执行上述流程300以使资方确定请求方的身份的正确性。在一些实施例中,可信设备160中的可信执行环境中部署有虚拟机,所述验证程序由请求方以智能合约的形式预先部署到所述可信执行环境中。
图4是根据本说明书一些实施例所示的另一种身份验证方法的示例性流程图。
本说明书的一些实施例中还提供了一种身份验证方法,该方法的中的一个或多个步骤可以由图1中的资方150执行,以通过融资请求跨链数据中的身份验证参数确定请求方的身份的正确性,流程400包括:
步骤410,获取请求方信息,所述请求方信息包括一个或多个身份验证参数。在一些实施例中,步骤410可以由请求方信息获取模块610执行。
在一些实施例中,请求方信息是用于验证请求方是否为验证程序的部署方的信息,在一些实施例中,请求方可以是融资事务中的业务方170,请求方信息和身份验证参数可以参见步骤210的相关描述,在此不再赘述。
步骤420,将所述一个或多个身份验证参数发送到可信设备,以便通过可信设备中的验证程序对所述一个或多个身份验证参数进行验证;所述验证程序由部署方预先部署到所述可信设备中。在一些实施例中,步骤420可以由验证请求发送模块620执行。
在一些实施例中,可信设备具有可信执行环境,将所述一个或多个身份验证参数发送到可信设备,以便通过可信设备中的验证程序对所述一个或多个身份验证参数进行验证可以参见步骤310~步骤340相关描述,在此不再赘述。
在一些实施例中,所述可信执行环境中部署有虚拟机;所述验证程序由请求方以智能合约的形式预先部署到所述可信执行环境中。
步骤430,接收可信设备返回的业务方170身份验证结果,所述业务方170身份验证结果指示所述业务方170为所述部署方。在一些实施例中,步骤430可以由结果接收模块630执行。
在一些实施例中,可信设备返回的请求方身份验证结果包括身份验证通过或不通过,当身份验证通过时,即请求方与部署方(或目标业务方)吻合,在融资事务中,可以确认请求方身份的正确性;当身份验证不通过时,即请求方可能并非验证程序的部署方,此时请求方身份有误,可以拒绝融资申请。
应当注意的是,上述有关流程200~流程400的描述仅仅是为了示例和说明,而不限定本说明书的适用范围。对于本领域技术人员来说,在本说明书的指导下可以对流程200~流程400进行各种修正和改变。然而,这些修正和改变仍在本说明书的范围之内。
图5是根据本说明书一些实施例所示的一种身份验证系统的示例性模块图。
如图5所示,该身份验证系统500可以包括程序部署模块510、验证请求接收模块520、身份验证执行模块530和验证结果返回模块540。这些模块也可以作为应用程序或一组由处理引擎读取和执行的指令实现。此外,模块可以是硬件电路和应用/指令的任何组合。例如,当处理引擎或处理器执行应用程序/一组指令时,模块可以是处理器的一部分。
程序部署模块510可以用于接收部署方发送的验证程序,并将其部署在可信执行环境中。
关于验证程序的更多描述可以在本说明书的其他地方(如步骤310及其相关描述中)找到,在此不作赘述。
验证请求接收模块520,用于接收核验请求方发送的身份验证请求;所述身份验证请求至少包括一个或多个身份验证参数。
关于身份验证请求的更多描述可以在本说明书的其他地方(如步骤320及其相关描述中)找到,在此不作赘述。
身份验证执行模块530,用于执行所述验证程序,以判断所述一个或多个身份验证参数是否满足预设条件或预设关系,进而获得指示所述一个或多个身份验证参数是否来自所述部署方的身份验证结果。
关于身份验证结果的更多描述可以在本说明书的其他地方(如步骤330及其相关描述中)找到,在此不作赘述。
验证结果返回模块540,用于将所述身份验证结果返回给核验请求方。
关于返回给核验请求方的更多描述可以在本说明书的其他地方(如步骤340及其相关描述中)找到,在此不作赘述。
图6是根据本说明书一些实施例所示的另一种身份验证系统的示例性模块图。
如图6所示,该身份验证系统600可以包括请求方信息获取模块610、验证请求发送模块620和结果接收模块630。这些模块也可以作为应用程序或一组由处理引擎读取和执行的指令实现。此外,模块可以是硬件电路和应用/指令的任何组合。例如,当处理引擎或处理器执行应用程序/一组指令时,模块可以是处理器的一部分。
请求方信息获取模块610,用于获取请求方信息,所述请求方信息包括一个或多个身份验证参数。
关于获取请求方信息的更多描述可以在本说明书的其他地方(如步骤410及其相关描述中)找到,在此不作赘述。
验证请求发送模块620,用于将所述一个或多个身份验证参数发送到可信设备,以便通过可信设备中的验证程序对所述一个或多个身份验证参数进行验证;所述验证程序由部署方预先部署到所述可信设备中。
关于对所述身份验证参数进行验证的更多描述可以在本说明书的其他地方(如步骤420及其相关描述中)找到,在此不作赘述。
结果接收模块630,用于接收可信设备返回的请求方身份验证结果,所述请求方身份验证结果指示所述请求方是否为所述部署方。
关于对接收可信设备返回的请求方身份验证结果的更多描述可以在本说明书的其他地方(如步骤430及其相关描述中)找到,在此不作赘述。
应当理解,图5和图6所示的装置及其模块可以利用各种方式来实现。例如,在一些实施例中,装置及其模块可以通过硬件、软件或者软件和硬件的结合来实现。其中,硬件部分可以利用专用逻辑来实现;软件部分则可以存储在存储器中,由适当的指令执行装置,例如微处理器或者专用设计硬件来执行。本领域技术人员可以理解上述的方法和装置可以使用计算机可执行指令和/或包含在处理器控制代码中来实现,例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本说明书的装置及其模块不仅可以有诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现,也可以用例如由各种类型的处理器所执行的软件实现,还可以由上述硬件电路和软件的结合(例如,固件)来实现。
需要注意的是,以上对于数据下载装置及其模块的描述,仅为描述方便,并不能把本说明书限制在所举实施例范围之内。可以理解,对于本领域的技术人员来说,在了解该装置的原理后,可能在不背离这一原理的情况下,对各个模块进行任意组合,或者构成子装置与其他模块连接。例如,图4中验证请求接收模块520和验证结果返回模块540可以为同一个模块,任意模块在接收请求后又发送结果。又例如,系统中的各个模块可以位于同一服务器上,也可以分属不同的服务器。诸如此类的变形,均在本说明书的保护范围之内。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
本说明书实施例可能带来的有益效果包括但不限于:(1)通过区块链网络保证融资事务中的数据和信息的安全性;(2)通过可信执行环境,使得资方可以通过可信设备验证请求方身份的真实性,同时无法得到其他任何信息;(3)通过身份验证参数进行身份验证,资方无需储存较多业务方密钥,降低了传输压力以及资方的密钥维护开销;(4)验证逻辑在可信设备中实现,资方可以实现零知识身份验证,降低资方技术成本。
需要说明的是,不同实施例可能产生的有益效果不同,在不同的实施例里,可能产生的有益效果可以是以上任意一种或几种的组合,也可以是其他任何可能获得的有益效果。
上文已对基本概念做了描述,显然,对于本领域技术人员来说,上述详细披露仅仅作为示例,而并不构成对本说明书的限定。虽然此处并没有明确说明,本领域技术人员可能会对本说明书进行各种修改、改进和修正。该类修改、改进和修正在本说明书中被建议,所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。
同时,本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此,应强调并注意的是,本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外,本说明书的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。
此外,除非权利要求中明确说明,本说明书所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用,并非用于限定本说明书流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例,但应当理解的是,该类细节仅起到说明的目的,附加的权利要求并不仅限于披露的实施例,相反,权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如,虽然以上所描述的系统组件可以通过硬件设备实现,但是也可以只通过软件的解决方案得以实现,如在现有的服务器或移动设备上安装所描述的系统。
同理,应当注意的是,为了简化本说明书披露的表述,从而帮助对一个或多个发明实施例的理解,前文对本说明书实施例的描述中,有时会将多种特征归并至一个实施例、附图或对其的描述中。但是,这种披露方法并不意味着本说明书对象所需要的特征比权利要求中提及的特征多。实际上,实施例的特征要少于上述披露的单个实施例的全部特征。
一些实施例中使用了描述成分、属性数量的数字,应当理解的是,此类用于实施例描述的数字,在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明,“大约”、“近似”或“大体上”表明所述数字允许有±20%的变化。相应地,在一些实施例中,说明书和权利要求中使用的数值参数均为近似值,该近似值根据个别实施例所需特点可以发生改变。在一些实施例中,数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本说明书一些实施例中用于确认其范围广度的数值域和参数为近似值,在具体实施例中,此类数值的设定在可行范围内尽可能精确。
针对本说明书引用的每个专利、专利申请、专利申请公开物和其他材料,如文章、书籍、说明书、出版物、文档等,特此将其全部内容并入本说明书作为参考。与本说明书内容不一致或产生冲突的申请历史文件除外,对本说明书权利要求最广范围有限制的文件(当前或之后附加于本说明书中的)也除外。需要说明的是,如果本说明书附属材料中的描述、定义、和/或术语的使用与本说明书所述内容有不一致或冲突的地方,以本说明书的描述、定义和/或术语的使用为准。
最后,应当理解的是,本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书的范围。因此,作为示例而非限制,本说明书实施例的替代配置可视为与本说明书的教导一致。相应地,本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。